| 00:02 | <JonathanNeal> | TabAtkins: Okay, like this now? |
| 00:02 | <TabAtkins> | Yes. |
| 00:04 | <JonathanNeal> | Hurray! |
| 00:08 | <Krinkle> | TabAtkins: Thx for bring up https://github.com/whatwg/html/issues/127 – I assume it's no coincidence following our chat the other day? |
| 00:15 | <TabAtkins> | Krinkle: Correct, it's a direct result of that chat. |
| 00:16 | <Krinkle> | Exciting :) |
| 00:16 | <Krinkle> | I'm curious if you have any <s>bikeshed</s> advice on what a polyfill would look like. |
| 00:17 | <Krinkle> | Give me your best/worst :D |
| 00:17 | <JonathanNeal> | document.addEventListener('DOMContentLoaded', Promise.resolve); ? |
| 00:17 | <Krinkle> | JonathanNeal: The problem is not knowing whether the event already fired. |
| 00:18 | <Krinkle> | Async code |
| 00:18 | <JonathanNeal> | document.ready = new Promise(function (resolve) { document.addEventListener('DOMContentLoaded', resolve); }); ? |
| 00:18 | <Krinkle> | In addition to async code, also async code that loads more async code (<script async> conveniently holds back window.onload, but that doesn't apply to any script added to the DOM later) |
| 00:19 | <Krinkle> | JonathanNeal: That code will be pending indefinitely if run after the event already fired. |
| 00:20 | <JonathanNeal> | Krinkle: is `readyState` part of the official API? |
| 00:21 | <TabAtkins> | I think it is? |
| 00:22 | <Krinkle> | The question is also, if you check it, is it safe to always add a new event or is there a grey area where it's not ready but also won't take new events. |
| 00:22 | <JonathanNeal> | document.ready = new Promise(function (resolve) { document.readyState === 'complete’ ? resolve() : document.addEventListener('DOMContentLoaded', resolve); }); - though you may want to expand on it to clear out the event object. |
| 00:22 | <TabAtkins> | Yes, readyState is specified on Document in HTML. |
| 00:22 | <JonathanNeal> | `document.ready = new Promise(function (resolve) { document.readyState === 'complete’ ? resolve() : document.addEventListener('DOMContentLoaded', resolve); });` though you may want to expand on it to clear out the event object. |
| 00:23 | <Krinkle> | window.onload has this with performance.loadEventStart where I believe you can't attach new events from within an onload handler, but it's also not finished yet. Though I guess window.onload (the hidden event) is right before it, not after. |
| 00:23 | <JonathanNeal> | Sorry that came twice, irccloud told me the previous one was not sent. |
| 00:50 | <Krinkle> | JonathanNeal: Hm.. yeah. I suppose it is relatively straight forward with dom ready |
| 00:50 | <Krinkle> | JonathanNeal: What about window.onload though? |
| 00:50 | <Krinkle> | I haven't found a way to do that short using performance.timing.loadEventEnd – which isn't very available yet. |
| 00:51 | <Krinkle> | or loadEventStart I suppose |
| 00:51 | <JonathanNeal> | Well, I may have mispoke earlier, but this should do it: http://stackoverflow.com/questions/11528132/determining-whether-the-window-has-loaded-without-using-any-global-variables/11543156#11543156 |
| 00:56 | <Krinkle> | There sure is a lot of click bate and confusion out on stackoverflow. Lots of questions about how to detect window load, all saying to check readyState or use jQuery. Which is irrelevant to the question. |
| 00:57 | <Domenic> | Why not just load the polyfill script in your <head> |
| 00:58 | <Krinkle> | That's a fair requirement once there is somewhat of an established standard. But for individual libraries it seems odd to have to require them to put something arbitrary in a head script. |
| 00:58 | <Krinkle> | E.g. imagine the next version of google analytics or jquery requiring you put something in <head> |
| 00:59 | <JonathanNeal> | Yea, it’s unlikely. It was hard enough for html5shiv. |
| 01:01 | <Krinkle> | In my case it's two fold. In production there's an async loaded module that collects Navigation Timing, which can sort of get away by checking or polling performance.timing.loadEvent* since it itself won't do anything if nav timing is unsupported. The other is random experiments that are loaded from a user space, which don't have the ability to modify the |
| 01:01 | <Krinkle> | main page. |
| 01:02 | <Domenic> | Sure, I thought you were talking about a polyfill, not a library. |
| 01:03 | <JonathanNeal> | But a polyfill has to be willing to work with what it has, and can’t guaruntee markup position. |
| 01:15 | gsnedder1 | wonders if he's an idiot or if he's found a bug in AAA |
| 01:26 | <Krinkle> | JonathanNeal: Yeah, sorry for the confusion. I mean more that if there's a polyfill, it'd be slightly more feasible to have it load from a certain position. Whereas in the here and now, ad-hoc libraries loaded without guarantees need something potentially more solid. |
| 01:27 | <Krinkle> | Though yeah,ideally the polyfill would be embeddable as small micro library in any other library that needs it. |
| 01:27 | <JonathanNeal> | They need something that, to borrow an expression, does the right thing. |
| 01:28 | <TabAtkins> | JonathanNeal: You don't want "complete" (that's the load event), you want "interactive" (that'd DOMContentReady). |
| 01:28 | <TabAtkins> | JonathanNeal: You don't want "complete" (that's the load event), you want "interactive" (that'd DOMContentReady). |
| 01:28 | <JonathanNeal> | ^ yes, as referenced in the stackoverflow I shared. |
| 01:28 | <TabAtkins> | Ah, sorry, didn't read. |
| 01:29 | <JonathanNeal> | My fault for mispeaking to begin with. |
| 01:31 | <JonathanNeal> | But “interactive” and “complete” should provide the events you are looking for Krinkle. If I were to write a polyfill, I might use readystatechange to try and be clever. |
| 01:31 | <JonathanNeal> | ^ https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState |
| 01:31 | <Krinkle> | JonathanNeal: but those relate to the html payload, not the subresources. |
| 01:31 | <Krinkle> | window load, not document read/load |
| 01:31 | <JonathanNeal> | Read the definition for “complete” in that MDN link I just shared. |
| 01:32 | <Krinkle> | Interesting |
| 01:32 | <Krinkle> | I guess I was thrown off because it's on the document |
| 01:32 | <Krinkle> | cool :) |
| 01:33 | <Krinkle> | DOMComplete in Nav Timing is not the same as document.readyState=complete, then. |
| 01:33 | <Krinkle> | Hm.. the spec describes it as when readyState reaches "complete" |
| 01:34 | Krinkle | does some field tests |
| 01:34 | <MikeSmith> | Domenic: have at it https://github.com/whatwg/html-build/commit/a2135b8e7f136138edd48c9cfb980f585c683243 |
| 01:36 | <gsnedders> | Nope. no bug in the AAA. |
| 01:36 | <gsnedders> | I'm just an idiot. |
| 01:38 | <JonathanNeal> | Krinkle: what are the two events you want? document.ready and ? |
| 01:38 | <Krinkle> | DOMContentLoaded and window.onload |
| 01:39 | <Krinkle> | What we'll name the promises I don't mind. Though having "DOMContentLoaded" be "document.ready" would be a huge plus since that's become an idiom on the web that people identify with. |
| 01:40 | <JonathanNeal> | The name of the Promise property, I mean. Just best guess. |
| 01:40 | <JonathanNeal> | document.ready and document.load ? |
| 01:55 | <Krinkle> | Yeah, though I can imagine there would be confusion. |
| 01:55 | <Krinkle> | Taking it off window seems nice, though I'm not sure why or if that's inline with other things happening in dom |
| 01:56 | <Krinkle> | http://codepen.io/Krinkle/pen/pjgGEY?editors=001 |
| 01:57 | <JonathanNeal> | Krinkle: https://gist.github.com/jonathantneal/fba8689eaa288aeee11b |
| 02:00 | <JonathanNeal> | That gives you what you want, I think. Rather than muck around with names, I just used the ones onreadystate already gives us, which are actually quite easy to remember. |
| 02:00 | <Krinkle> | Yeah, once you understand. |
| 02:01 | <Krinkle> | I can't believe I never understood readyState until now |
| 02:01 | <Krinkle> | JonathanNeal: nit pick, but I believe that leaves the handler of interactive behind if complete is reached |
| 02:02 | <Krinkle> | may be pass an array of regex instead. |
| 02:02 | <Krinkle> | or* |
| 02:02 | <JonathanNeal> | Um, no it should fire even if complete is reached first. |
| 02:03 | <JonathanNeal> | You could run that code in your browser right now and your window would be complete and document.interactive would also be resolved. |
| 02:03 | <Krinkle> | Yes |
| 02:03 | <Krinkle> | I mean the event handler if 'interactive' will linger if 'complete' is already reached, unlike the other two which go out of their way to clean up |
| 02:04 | Krinkle | spent 8 hours doing code review today. |
| 02:05 | <JonathanNeal> | Yes, fixed. |
| 02:06 | <Krinkle> | nice |
| 02:06 | <MikeSmith> | Krinkle: 8 hours of code review sounds grim |
| 02:06 | <Krinkle> | My brain practically runs JS native now |
| 02:08 | <JonathanNeal> | Krinkle: so besides requiring an include polyfill, does that cover your use cases? Kind of nice and consistent to reuse the readystate names, I think. |
| 02:08 | <Krinkle> | I'm letting in sink in. It's too simple. |
| 02:08 | <Krinkle> | I demand an uglier implementation |
| 02:10 | <Krinkle> | So yeah, ES7(array) and ES6(Promise) aside, I'm thinking how far back this will run in browsers. |
| 02:11 | <Krinkle> | Down to say IE8 (no further) |
| 02:11 | <Krinkle> | attachEvent naturally, but that's simple |
| 02:14 | <Krinkle> | especially since https://github.com/jquery/jquery/blob/1.11-stable/src/core/ready.js is much more elaborate and that's only for dom.interactive essentially |
| 02:37 | <JonathanNeal> | mmhmm |
| 02:59 | <Domenic> | I agree with zcorpan_ that we should not do onload, just DOMContentLoaded. |
| 04:58 | <Krinkle> | JonathanNeal: Hm.. should that event listener be for readystatechange instead of DOMContentLoaded at https://gist.github.com/jonathantneal/fba8689eaa288aeee11b ? |
| 04:58 | <JonathanNeal> | What are you talking about, it is! :P |
| 05:02 | <JonathanNeal> | Thanks Krinkle |
| 05:04 | <Krinkle> | JonathanNeal: I'm trying it out at the moment and find some issues. |
| 05:04 | <Krinkle> | So the assumption that DOMComplete/document.readyState=complete/window.onload are the same is incorrect. |
| 05:04 | <Krinkle> | It is correct in the sense that very little happens in the browser |
| 05:05 | <Krinkle> | However the userland is notably different because readyState=complete is before the loadEvent starts/ends |
| 05:05 | <Krinkle> | which means it can't be used for a lot of things, such as collecting performance.timing (my current usecase) |
| 05:05 | <Krinkle> | Because the last two properties (loadEventStart/End) would still be 0 |
| 05:06 | <Krinkle> | Right now we use a mixture of $(window).on('load') and polling performance.timing.loadEventEnd in an interval loop |
| 05:06 | <JonathanNeal> | You mean readyState “complete” !== window.load? |
| 05:06 | <Krinkle> | Indeed |
| 05:07 | <Krinkle> | It's a little bit before it |
| 05:07 | <JonathanNeal> | Does “complete” fire after all the assets have loaded, like “load"? |
| 05:07 | <Krinkle> | I believe so, but I'm not sure. |
| 05:07 | <Krinkle> | So I think for most purposes it is conceptually the same, but it can be more than one event look tick away from the real onload |
| 05:09 | <Krinkle> | We've gone over many iterations and the current code looks like this. I'm working on refactoring this pretty much from the ground up. https://github.com/wikimedia/mediawiki-extensions-NavigationTiming/blob/master/modules/ext.navigationTiming.js#L160-L178 |
| 05:09 | <Krinkle> | I really want to get rid of that polling loop |
| 05:10 | <Krinkle> | before we loaded scripts asynchronously it was: $(window).on('load', function () {setTimeout(collectNavTiming); }); which reliably got everything. |
| 05:11 | <Krinkle> | http://codepen.io/Krinkle/pen/rOxRjm?editors=001 |
| 05:12 | <JonathanNeal> | It makes sense that it might be one tick before the real onload. |
| 05:12 | <JonathanNeal> | If for no other reason that it happens “deeper” |
| 05:14 | <Krinkle> | It seems fragile to rely on the fact that setTimeout() from document readyState==complete is after window.onload callbacks finish |
| 05:14 | <Krinkle> | I'll give it a try and run it in some browsers |
| 05:55 | <annevk> | zcorpan_: https://bugzilla.mozilla.org/show_bug.cgi?id=1203404 |
| 07:13 | <annevk> | MikeSmith: hey can you explain to me what "ln -s ../link-fixup.js $HTML_TEMP/wattsi-output/multipage-html/" does in the build script? |
| 07:14 | <annevk> | MikeSmith: hmm, back in 30-60min or so |
| 07:14 | <annevk> | MikeSmith: I'd like to figure out how we can have link-fixup.js only appear in /multipage/ since now we duplicate the file and that's not needed |
| 07:14 | <annevk> | MikeSmith: on the server that is |
| 07:17 | <annevk> | MikeSmith: alternatively I guess we change wattsi to just point to /link-fixup.js |
| 07:17 | <annevk> | MikeSmith: or maybe generate link-fixup.js just like it does for fragment-links.js |
| 07:20 | <zcorpan_> | annevk: thanks. see https://www.w3.org/Bugs/Public/show_bug.cgi?id=16673 -- i suppose it was a mistake to hook into the dispatch flag? |
| 07:36 | <JonathanNeal> | :facepalm: |
| 07:37 | <JonathanNeal> | ^ re: do not cc the entire list |
| 07:41 | <zcorpan_> | JonathanNeal: ? |
| 07:42 | <JonathanNeal> | nvm :) |
| 07:48 | <annevk> | zcorpan_: yeah, you want to calculate them when the event object is created |
| 07:56 | <zcorpan_> | annevk: hmm yes that does make more sense |
| 07:58 | zcorpan_ | looks at https://w3c.github.io/uievents/#interface-MouseEvent |
| 07:59 | <annevk> | zcorpan_: I think we really want to merge CSSOM into that |
| 07:59 | <annevk> | zcorpan_: it doesn't make much sense to define MouseEvent in two different places |
| 07:59 | <annevk> | MikeSmith: I ended up filing an issue against html-build to sort out the file duplication |
| 07:59 | <annevk> | MikeSmith: I've figured out how it could be fixed, just need agreement |
| 08:19 | <schalkneethling> | So, in step 9 here https://html.spec.whatwg.org/#concept-media-load-algorithm the fetch algorithm will always be called with a URL unless the source was a data-uri, a blob, or a file object correct? So, that means that for a lot of scenarios the fetch algorithm's mode is remote "fork" will be executed and so, if you want to do anything other than play/pause/stop the video you must include crossorigin either set to anonymous or use-creden |
| 08:50 | <annevk> | schalkneethling: data and blob URLs go through Fetch |
| 08:50 | <annevk> | schalkneethling: "mode is object" is about objectSrc |
| 08:50 | <annevk> | schalkneethling: afaik |
| 08:52 | <schalkneethling> | annevk: oh, so setting objectSrc via JS will cause mode is local to be followed by the fetch algorithm but, blob and data will still go through the mode is remote path? |
| 08:53 | <schalkneethling> | referring to this part: https://html.spec.whatwg.org/#concept-media-load-resource |
| 08:54 | <annevk> | schalkneethling: blob and data URLs, I think so yes |
| 08:54 | <schalkneethling> | and I guess a File object is a blob as well right? |
| 08:55 | <schalkneethling> | so essentially the Fetch algorithm will always follow the mode is remote path unless the objectSrc was set by JS |
| 08:55 | <annevk> | schalkneethling: a File is a subclass of Blob |
| 08:56 | <annevk> | schalkneethling: reading this I think that's the case, though admittedly it's not entirely clear to me either |
| 08:56 | <annevk> | schalkneethling: philipj would know |
| 08:56 | <philipj> | annevk: soemthing about Blob/File? |
| 08:56 | <schalkneethling> | yes, so it will essentially receive the same treatment although, I reckon in most scenarios, JS will handle the File upload process and then probably set the objectSrc in which case it will go down the mode is local path |
| 08:57 | <philipj> | If we're talking about media elements, then s/objectSrc/srcObject/g |
| 08:58 | <schalkneethling> | philipj: so, trying to understand when the fetch algorithm will go down the mode is remote path and when it will go down the mode is local path |
| 08:58 | <schalkneethling> | so, it seems to state that is the media element is a URL it will go down remote else local |
| 08:59 | <schalkneethling> | so the question is, is the only way for it to not be a URL to set the objectSrc/srcObject via JS |
| 08:59 | <schalkneethling> | and that is the only way Fetch will ever follow the mode is local path |
| 09:01 | <schalkneethling> | philipj: referring to this part of the spec https://html.spec.whatwg.org/#concept-media-load-resource |
| 09:01 | <philipj> | schalkneethling: are you trying to implement srcObject in a browser, and if so which one? |
| 09:02 | <schalkneethling> | philipj: oh no :) just trying to wrap my mind around it and understand the crossorigin attribute's role here |
| 09:03 | <philipj> | so I haven't tried to implement this yet, but basically there's a fork point in the resource selection algorithm, which I'm sure you've found |
| 09:03 | <schalkneethling> | it kinda seems that anytime you want to do more with the video data other than simply play/pause/stop you wanna specify the crossorigin attribute |
| 09:03 | <philipj> | and if it's a src object, then there's no networking involved, nor do I think the crossorigin attribute could have any effect |
| 09:04 | <schalkneethling> | agreed, so this point "If mode is object" |
| 09:04 | <annevk> | schalkneethling: well, only if your URLs are actually cross-origin does crossorigin="" have any effect |
| 09:04 | <philipj> | the spec now says "The resource described by the current media resource, if any, contains the media data. It is CORS-same-origin." |
| 09:04 | <annevk> | schalkneethling: if you just have same-origin URLs you can do anything you want and you won't need it |
| 09:05 | <schalkneethling> | oooh, I thought you needed to specify crossorigin=anonymous for same origin |
| 09:05 | <schalkneethling> | if you wanted to do stuff on a canvas |
| 09:05 | <schalkneethling> | does this mean, it will load subtitle tracks as well as long as those reside on the same origin |
| 09:06 | <philipj> | in-band text tracks aren't actually well implemented, but yes, same-origin media resources would give you full access to the text tracks |
| 09:07 | <schalkneethling> | hmmmm, ok. so then essentially for same origin there is no need to use crossorigin but, for cross-origin you need to use crossorigin and set it to use-credentials |
| 09:07 | <schalkneethling> | but then the use case for anonymous becomes kinda foggy |
| 09:07 | <schalkneethling> | perhaps I do not understand what those credentials are? |
| 09:19 | <schalkneethling> | This "A media provider object is an object that can represent a https://html.spec.whatwg.org/#media-resource, separate from a https://html.spec.whatwg.org/#url. https://html.spec.whatwg.org/#mediastream objects, https://html.spec.whatwg.org/#mediasource objects, https://html.spec.whatwg.org/#blob objects, and https://html.spec.whatwg.org/#file objects are all https://html.spec.whatwg.org/#media-provider-object."; seems to suggest that the |
| 09:20 | <schalkneethling> | so, crossorigin is not a concern when using either of those types as a source |
| 09:21 | <schalkneethling> | but when specifying the value for either the src or source attribute/element crossorigin does come into play if that src is not of the same origin |
| 09:22 | <schalkneethling> | so, that leaves anonymous which is a little dubious |
| 09:32 | <annevk> | schalkneethling: credentials are just cookies, that may have been set for the domain in question |
| 09:32 | <schalkneethling> | ah so srcObject is the type of object |
| 09:33 | <schalkneethling> | and currentSrc is the actual location of the data object |
| 09:34 | <JakeA> | annevk: are non-tag members welcome to comment on https://github.com/w3ctag/spec-reviews/issues/76? |
| 09:34 | <schalkneethling> | so, anonymous might say something like "load this URL but ignore any cookies set for this domain" whereas use-credentials will say "load this URL and pass along/use/expose any cookies that has been set for this domain" |
| 09:35 | <schalkneethling> | so in essence, anonymous is a security measure to prevent credentials/cookies leaking across domains |
| 09:37 | <annevk> | JakeA: well I'm not a member, so yes |
| 09:37 | <JakeA> | annevk: I don't understand timbl's comment, it seems to be some combination of "the default for withCredentials is wrong", but the end seems to be questioning the need for CORS in anonymous requests entirely… am I reading it right? |
| 09:39 | <annevk> | JakeA: he wants something different from the current protocol |
| 09:39 | <annevk> | JakeA: what he wants is give me the best response for a given URL |
| 09:40 | <annevk> | JakeA: without knowing whether that requires credentials or not |
| 09:41 | <annevk> | JakeA: per CORS that requires up to two fetches (three perhaps if a preflight is required) since you don't know if the resource "supports credentials" or not |
| 09:41 | <annevk> | JakeA: he doesn't like it |
| 09:41 | <annevk> | JakeA: and I'm just pointing out that you'll have the same problem with anything the resource might vary on |
| 09:41 | <nox> | gsnedders: Aren't the isindex tests wrong? |
| 09:42 | <JakeA> | annevk: credentials:"ideally" - I guess the two request thing is less of an issue in HTTP/2, but I'm not sold on the feature, it's not something I've ever needed. |
| 09:42 | <nox> | gsnedders: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cisindex%20action%3D%22x%22%3E |
| 09:43 | <nox> | Oh, document-fragment context. |
| 09:43 | <annevk> | JakeA: yeah, I don't think this is going to result in something, someone can write a library I suppose |
| 09:43 | <annevk> | JakeA: pretty easy to write a varyCredentialsFetch() |
| 09:43 | <zcorpan_> | nox: blink has dropped isindex special parsing, if you mean that |
| 09:44 | <nox> | zcorpan_: No I mean '<isindex action="x">' as a table fragment. |
| 09:44 | <JakeA> | annevk: his final paragraph… is he looking for a way to get data from a response that doesn't explicitly allow it? (there's an internal devrel thread making this claim, and I'm not confident) |
| 09:46 | <annevk> | JakeA: his final paragraph is just saying that if we need CORS (which we do) we should do whatever it takes to make his scenario work |
| 09:47 | <annevk> | JakeA: his claim about the proxy server is wrong though, I guess I should point that out |
| 09:47 | <zcorpan_> | nox: i don't follow. which test are you talking about? |
| 09:48 | <nox> | zcorpan_: https://github.com/html5lib/html5lib-tests/pull/67/files#diff-654b5264d16ae0fd0b3d27f971f2d57cR259 |
| 09:48 | <JakeA> | Cheers! |
| 09:49 | <nox> | zcorpan_: I understand that the <hr> and <input> being siblings of <form> comes from the <table> context, but I don't think that's what it's supposed to do. |
| 09:50 | <zcorpan_> | nox: it's not what gecko does, at least. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3634 |
| 09:51 | <nox> | zcorpan_: I see "Pop that form element off the stack of open elements." for "form" start tag in "in table" insertion mode. |
| 09:51 | <nox> | But that's not the code path that code takes, AFAICT. |
| 09:51 | <zcorpan_> | <table><isindex> (non-fragment) is another interesting case |
| 09:51 | <nox> | zcorpan_: My Safari does as in the test. |
| 09:53 | <zcorpan_> | yeah |
| 09:54 | <schalkneethling> | annevk: philipj is my "thought process" re anonymous vs use-credentials correct in that anonymous will prevent leaking of credentials across domains by only "exposing" credentials for same origin requests and not cross-origin? |
| 09:54 | <zcorpan_> | for <table><isindex> webkit foster-parents the form and pops the form so the hr is a sibling |
| 09:54 | <nox> | zcorpan_: "If foster parenting is enabled and target is a table, tbody, tfoot, thead, or tr element:" |
| 09:54 | <nox> | zcorpan_: But target is not a table element, right? |
| 09:55 | <zcorpan_> | nox: are you discussing the <table>.innerHTML = '<isindex>' case? |
| 09:56 | <nox> | zcorpan_: Yes. |
| 09:56 | <schalkneethling> | so, you could do a cross-origin fetch and set crossorigin=anonymous and that way cookies are not shared with the third party |
| 09:57 | <schalkneethling> | so anonymous means make anonymous cross-origin requests and use-credentials identifies you to the third party by sharing credential cookies |
| 10:00 | <schalkneethling> | BTW, thanks a million for all your assistance so far |
| 10:01 | <annevk> | schalkneethling: it only identifies you if the third party had set a cookie for you before (or HTTP authentication or some existing TLS pool thingie) |
| 10:02 | <schalkneethling> | and only if you use "use-creentials" not "anonymous" |
| 10:03 | <annevk> | right |
| 10:03 | <schalkneethling> | if set to anonymous it will not use these credentials |
| 10:03 | <schalkneethling> | so if they are required, the requst will fail |
| 10:03 | <schalkneethling> | *request |
| 10:03 | <schalkneethling> | ok, I reckon I am getting to grips with this ;) |
| 10:03 | <annevk> | maybe, depends on how the server responds |
| 10:04 | <schalkneethling> | sure |
| 10:04 | <zcorpan_> | nox: /override target/ is only set in AAA, afaict, and that does not apply here |
| 10:05 | <zcorpan_> | nox: so target is the current node, which is <html> in the fragment case, right? |
| 10:05 | <nox> | zcorpan_: Yes. |
| 10:05 | <zcorpan_> | so many things to keep track of in the html parser :-( |
| 10:06 | <zcorpan_> | nox: ok so then "Let adjusted insertion location be inside target, after its last child (if any)." |
| 10:08 | <zcorpan_> | though the algorithm under "If foster parenting is enabled and target is a table, tbody, tfoot, thead, or tr element" has steps for the fragment case |
| 10:10 | <zcorpan_> | i suppose you can get there with <table>.innerHTML = '<tbody><p>' |
| 10:12 | <nox> | zcorpan_: Yes. |
| 10:12 | <nox> | zcorpan_: Are you going to take care of it? |
| 10:14 | <zcorpan_> | nox: i can PR the test, sure |
| 10:17 | <schalkneethling> | annevk: so this all then relates to https://fetch.spec.whatwg.org/#http-access-control-allow-credentials |
| 10:18 | <annevk> | schalkneethling: it does yes, it maps to https://fetch.spec.whatwg.org/#concept-request-credentials-mode as I mentioned earlier |
| 10:19 | <schalkneethling> | ah, must have missed that |
| 10:19 | <schalkneethling> | thanks |
| 10:19 | <nox> | zcorpan_: Thanks. |
| 10:22 | <zcorpan_> | nox: https://github.com/html5lib/html5lib-tests/pull/68 |
| 10:30 | <nox> | Cool. |
| 10:35 | <annevk> | zcorpan_: nox: also need to figure out <menuitem> at some point |
| 10:35 | <annevk> | zcorpan_: nox: whether it should remain void |
| 11:14 | <MikeSmith> | annevk: back now |
| 11:14 | <MikeSmith> | was out to dinner and such with N |
| 11:15 | <MikeSmith> | annevk: is the file/symlink thing resolved for now? or you still need me to do something? |
| 11:15 | <MikeSmith> | btw, the whatwg logo now has a permanent IPFS hash |
| 11:15 | <MikeSmith> | http://ipfs.pics/pic.php?id=QmbvGcNxAgVDpUBccHnNdxhj5VFaSaPgSXqLsEkj4wWL2i |
| 11:16 | <MikeSmith> | whatwg ye shall hereby be called QmbvGcNxAgVDpUBccHnNdxhj5VFaSaPgSXqLsEkj4wWL2i for posterity |
| 11:18 | <MikeSmith> | part of the idea of ipfs.pics is that once you upload an image that and it gets a hash, other images services can also store a copy of the image, with that same hash |
| 11:19 | <MikeSmith> | and so if ipfs.pics goes away, you can still address it by that same hash from any other place that has it |
| 11:22 | <MikeSmith> | annevk: also if/when you have a moment, maybe reply to this tweet https://twitter.com/tjconceptdk/status/644066686342164480 |
| 11:23 | <MikeSmith> | he seems like a clueful guy who would genuinely appreciate the info |
| 11:24 | <schalkneethling> | so is the Fetch standard a recommendation and implemented in user agents? Here is states that the spec does not use the "fetch" algorithm yet: https://html.spec.whatwg.org/#resource-sharing-check |
| 11:26 | <annevk> | schalkneethling: did I not point you to https://github.com/whatwg/html/issues/95? |
| 11:26 | <annevk> | MikeSmith: what is IPFS? |
| 11:27 | <annevk> | MikeSmith: I filed an issue on whatwg/html-build, would appreciate your opinion |
| 11:27 | <schalkneethling> | ah, so it is in process |
| 11:28 | <MikeSmith> | IPFS is an amibitious plan to create permanance/persistence for the Web in the face of domains expiring and people abandoing sites, etc. |
| 11:29 | <annevk> | MikeSmith: replied to the tweet |
| 11:29 | <MikeSmith> | it works in part by assigning hashes to the state of each particular resource at any particular time |
| 11:29 | <annevk> | MikeSmith: oh my |
| 11:30 | <MikeSmith> | https://ipfs.io/#how-it-works |
| 11:30 | <MikeSmith> | "IPFS combines a distributed hashtable, an incentivized block exchange, and a self-certifying namespace. IPFS has no single point of failure, and nodes do not need to trust each other." |
| 11:32 | <MikeSmith> | annevk: as far what "ln -s ../link-fixup.js $HTML_TEMP/wattsi-output/multipage-html/" does in the build, it makes a symlink that gets moved/copied into output/multipage along with the rest of the contents of that folder. Such that after the move, it just points to ./output/multipage/../link-fixup.js ーwhich is of course ./outline/link-fixup.js |
| 11:32 | <MikeSmith> | anyway, I will look at the issue |
| 11:45 | <annevk> | MikeSmith: could you merge WHATWG -> HTML - <img> into WHATWG -> HTML? |
| 11:45 | <annevk> | MikeSmith: or perhaps it's best to simply close it as well and transfer the bugs? |
| 11:49 | <MikeSmith> | annevk: yeah I think we should move the bugs and then close it |
| 11:49 | <MikeSmith> | I can do that |
| 11:50 | <MikeSmith> | zcorpan is OK with this? |
| 11:50 | <annevk> | oh cool |
| 11:50 | <annevk> | I haven't asked, I assume so |
| 11:50 | <zcorpan> | wat? |
| 11:50 | <annevk> | zcorpan: closing HTML - <img> component and moving the remaining bugs to the HTML component |
| 11:50 | <MikeSmith> | zcorpan: we transfer W3C bugzilla HTML <img> bugs to HTML componeentn |
| 11:52 | <zcorpan> | ok sure |
| 11:52 | <zcorpan> | but why |
| 11:52 | <zcorpan> | easier for other people to find the bugs? |
| 11:52 | <annevk> | zcorpan: yeah |
| 11:52 | <annevk> | zcorpan: they're not linked from the specification currently for instance |
| 11:56 | <zcorpan> | ok |
| 12:04 | <schalkneethling> | annevk: would appreciate feedback on this ~ https://sneethling.pastebin.mozilla.org/8846545 |
| 12:04 | <schalkneethling> | thx! |
| 12:06 | <annevk> | schalkneethling: the Fetch standard is not in process |
| 12:06 | <annevk> | schalkneethling: integration into HTML is |
| 12:06 | <schalkneethling> | aha, my bad |
| 12:07 | <schalkneethling> | will update |
| 12:07 | <annevk> | use-URL-credentials is not code |
| 12:07 | <schalkneethling> | yeah, I am using that to liberally I realized ;p |
| 12:08 | <MikeSmith> | related to IPFS, https://github.com/substack/html-version-spec/blob/master/readme.markdown#html-version-spec is a related idea/proposal worth reading |
| 12:08 | <annevk> | not a Fetch header, just a header |
| 12:08 | <MikeSmith> | "This specification builds on existing work in subresource integrity, link relation types for simple version navigation, and meta-version to provide a comprehensive versioning system for secure, signed, and permanent single-page web applications." |
| 12:10 | <schalkneethling> | thanks MikeSmith |
| 12:14 | <schalkneethling> | other than those two points, looking good annevk? |
| 12:15 | <annevk> | I guess |
| 12:15 | <Ms2ger> | annevk, would it make sense to assert at the start of (my implementation of) https://dom.spec.whatwg.org/#concept-event-dispatch that eventPhase is NONE and currentTarget is null? |
| 12:16 | <schalkneethling> | hmmm, sounds like there are some things you are not sure about |
| 12:16 | <annevk> | Ms2ger: seems reasonable |
| 12:16 | <Ms2ger> | Great, thanks |
| 12:17 | <annevk> | schalkneethling: well, it's not really clear who this is for and the bits you explain about CORS are only a small part of the story so it's not particularly clear why you picked those bits and not the others, etc. |
| 12:18 | <schalkneethling> | well, it would be aimed at web developers using the video element and perhaps not being familiar with the crossorigin attribute |
| 12:18 | <schalkneethling> | and a little broad overview of how it forms part of the larger framework of loading resources |
| 12:41 | <MikeSmith> | dang we were getting close to having only 300 open bugs before |
| 12:42 | <MikeSmith> | now 318 |
| 12:42 | <MikeSmith> | https://www.w3.org/Bugs/Public/buglist.cgi?component=HTML&list_id=59532&product=WHATWG&resolution=--- |
| 12:43 | <annevk> | MikeSmith: you ruined it! |
| 12:45 | <beverloo> | MikeSmith, annevk, fyi, we're killing the notification center (bell icon in the system tray), and notifications will either auto-dismiss after 8/25 (undecided) seconds or stay on-screen forever |
| 12:46 | <MikeSmith> | I blame you and zcorpan_ |
| 12:46 | <annevk> | beverloo: even on OS X? |
| 12:46 | <MikeSmith> | beverloo: glad to hear that |
| 12:46 | <beverloo> | yes, annevk |
| 12:46 | <beverloo> | Chrome OS keeps it as part of the OS, Android uses the OS' notification center, it's gone on Win/Mac/Linux |
| 12:47 | <annevk> | beverloo: how does that work? You simply don't integrate with the OS? |
| 12:47 | <beverloo> | usage statistics were in the realms of "it pretty much doesn't exist" |
| 12:47 | <MikeSmith> | I think the notification center approach is bad UX in practice |
| 12:47 | <beverloo> | yes, we found it to not work |
| 12:47 | <beverloo> | annevk, indeed. We're keeping our own toasts for now and won't (yet) move them to the OS' notification center after |
| 12:48 | <beverloo> | it's something we're looking at, but are yet undecided on. there's a huge variety in feature support on different platforms, and we'd be giving up all our flexibility |
| 12:48 | <Domenic> | beverloo: very sad there's no integration into the OS on desktop, especially Windows... I guess that's to be expected when all your devs use Linux though. |
| 12:48 | <beverloo> | (which is not necessarily a bad thing) |
| 12:48 | <Domenic> | Well, OK, now that you said your last line it sounds much more reasonable |
| 12:49 | <beverloo> | Domenic, we're actually looking at that, especially with Windows 10's new notification center :) |
| 12:49 | <Domenic> | \o/ |
| 12:53 | <MikeSmith> | beverloo: somewhat related to this, I been wanting to say that I find Gmail's currently-deployed notification behavior to not be so great, in that when I click a Gmail notification, it focuses a new window (instead of, say, some state of my existing gmail inbox tab), and then when I click a link from that gmail window, the window gets pushed down and the new page opens in my main browser window with all |
| 12:53 | <MikeSmith> | my tabs |
| 12:53 | <annevk> | Domenic: so if you're okay with path-absolute URLs, no changes to Wattsi would be required... |
| 12:53 | <annevk> | Domenic: we'd just update source |
| 12:54 | <beverloo> | MikeSmith, agreed |
| 12:54 | <beverloo> | I can't say much about it, but we're talking :) |
| 12:54 | <MikeSmith> | beverloo: and when I do that N number of times, I end up with N different useless windows sitting open in the background (which I then need to go back and manually close each one) |
| 12:54 | <MikeSmith> | beverloo: k |
| 12:59 | <Domenic> | annevk: ah that's true. I guess I am OK with that. |
| 13:02 | <annevk> | Domenic: combined with your patch to remove the images.whatwg.org thing I think we're all set then |
| 13:02 | <annevk> | Domenic: guess I'll wait for that to land first |
| 13:50 | <gsnedders> | nox: I think the vast majority are right. It's not impossible one or two slipped through. |
| 13:51 | <annevk> | MikeSmith: was https://github.com/validator cloning HTML intentional? |
| 13:53 | <MikeSmith> | yeah that was just for me to create a PR against mkwst's fork |
| 13:54 | <MikeSmith> | I will delete that validator fork now |
| 14:01 | <MikeSmith> | sento time; back in ~2hrs |
| 14:09 | <nox> | gsnedders: One was wrong, zcorpan made a PR. |
| 14:16 | <annevk> | Anyone use @htmlstandard recently? Just got an email from Twitter about potential account abuse... |
| 14:18 | <gsnedders> | nox: jgraham merged it hours ago :P |
| 14:18 | <nox> | Hah, didn't even notice. |
| 14:22 | <Domenic> | annevk: it was me, trying to add it to tweetdeck |
| 14:23 | <nox> | gsnedders: Are some svg attributes supposed to be dropped? |
| 14:24 | <gsnedders> | nox: Yes. Loads were removed ages from the spec. |
| 14:24 | <nox> | Never mind, completely misread the step. |
| 14:24 | <nox> | Is filterres special? |
| 14:25 | <gsnedders> | special how? |
| 14:25 | <nox> | Appearing out of nowhere like a wild pokémon. |
| 14:25 | <nox> | gsnedders: https://github.com/html5lib/html5lib-tests/blob/master/tree-construction/tests11.dat#L155 |
| 14:26 | <gsnedders> | I probably fucked up one of the merges. :) |
| 14:26 | <gsnedders> | nox: fucked up the merge. |
| 14:27 | <nox> | gsnedders: Just not here, I guess? |
| 14:27 | <nox> | Not just here* |
| 14:28 | <nox> | gsnedders: https://github.com/html5lib/html5lib-tests/pull/69 |
| 14:28 | <gsnedders> | nox: tl;dr: it's an attribute that got dropped |
| 14:30 | <nox> | gsnedders: TL;DR LGTM. :P |
| 14:31 | <gsnedders> | nox: soz, trying to do ten things at once :P |
| 14:31 | <nox> | Oh, or was the test supposed to check that filterres doesn't become filterRes? |
| 14:32 | <Ms2ger> | Yeah |
| 14:32 | <nox> | Ms2ger: Fixed. |
| 14:33 | <gsnedders> | hmm, yeah, we probably ought have tests checking they don't get changed |
| 14:33 | <gsnedders> | bah, I did the wrong thing in the merge, I guess. |
| 14:33 | <gsnedders> | Because Blink just removed them from the tests altogether |
| 14:33 | <gsnedders> | I'd suggest having the not-converted attributes in a different tests, though. |
| 14:34 | <nox> | gsnedders: I leave that as an exercice to the next person. :P |
| 14:46 | <ccardona-work> | Good morning/afternoon/evening WHATWG crew o/ |
| 14:55 | <annevk> | I was thinking, we could have something related to a kitchen sink as logo for @htmlstandard |
| 15:02 | <Ms2ger> | s/could/MUST/ :) |
| 15:31 | <annevk> | Domenic: I think there's a few places where attributes have states, and then whatever is the current state is called the mode... |
| 15:31 | <Domenic> | annevk: I haven't seen mode anywhere else |
| 15:32 | <Domenic> | e.g. "If an HTML element's translate attribute is in the yes state" |
| 15:33 | <Domenic> | maps to a *separate* concept of translation mode |
| 15:33 | <Domenic> | but the attribute has a state, not a mode |
| 15:33 | <Domenic> | And there's an explicit mapping between the attribute states and the translate modes |
| 15:33 | <annevk> | "mode being the current state of the element's crossorigin content attribute" |
| 15:33 | <Domenic> | yeah the current spec has this confusion, i agree |
| 15:33 | <Domenic> | but it is very confusing |
| 15:34 | <Domenic> | and doesn't match any other attributes |
| 15:34 | <annevk> | I guess I can just rename it all to state, I don't care strongly |
| 15:35 | <Domenic> | yes please :) |
| 15:35 | <annevk> | Domenic: before I do that, did you review the changes? If so I'll rebase first |
| 15:36 | <annevk> | Meh never mind |
| 15:37 | <Domenic> | annevk: yeah looks good |
| 15:48 | <annevk> | Domenic: heh, my own noexport patch made rebasing harder |
| 15:48 | <annevk> | Domenic: anyway, rebasing is done, I didn't squash yet since I guess we are not done yet... |
| 15:51 | <gsnedders> | Ergh. I hate how practically impossible it is to state what meta elements have any affect on SEO. |
| 15:51 | <Domenic> | annevk: sorry, will try to finish review within the next few hours... |
| 15:52 | <annevk> | Domenic: no worries |
| 16:06 | <annevk> | "Cookies respect SOP by design" oh public-webappsec... |
| 16:41 | <Krinkle> | JonathanNeal: The saga continues. I've fixed support for IE8 by using attachEvent which works as expected. However the only one broken still is Android 2.3 (ugh). It doesn't implement readystatechange. It does implement DOMContentLoaded, but that's when interactive happens, not complete. |
| 16:42 | <Krinkle> | And in fact it also has readyState (property) incorrect, it uses "loading" and "loaded". Not interactive or complete. And it |
| 16:42 | <Krinkle> | 's loaded matches "interactive" |
| 16:43 | <Krinkle> | Progress at http://codepen.io/Krinkle/pen/rOxRjm?editors=001 |
| 16:45 | <Krinkle> | or here https://gist.github.com/Krinkle/fc0b4d4626f2409219ee |
| 16:55 | <Matt5ander5> | test |
| 17:08 | <annevk> | Domenic: what about https://github.com/whatwg/html/pull/144#issuecomment-140643963? |
| 17:09 | <annevk> | Krinkle: so are you planning on working on source maps? Since we have this repo... |
| 17:23 | <Krinkle> | annevk: I'm waiting for reply from the mailing list |
| 17:24 | <annevk> | Krinkle: source map mailing list? |
| 17:24 | <Krinkle> | Yeah |
| 17:24 | <Krinkle> | They don't seem to be interested. |
| 17:25 | <Krinkle> | https://groups.google.com/forum/#!topic/mozilla.dev.js-sourcemap/SD8sZ_7VFpw |
| 17:27 | <Krinkle> | annevk: I suppose we can delete the repo fo rnow |
| 17:28 | <JonathanNeal> | Krinkle: Andoird 2.3 is still a thing |
| 17:28 | <JonathanNeal> | ? |
| 17:28 | <annevk> | Krinkle: maybe that's better so nobody gets the impression we step on their turf |
| 17:28 | <Krinkle> | annevk: Yeah, fine by me :) |
| 17:28 | <Krinkle> | JonathanNeal: Enough of a thing that we support it. |
| 17:29 | <Krinkle> | And adding a primitive like this requires support there, otherwise random things will start to fail there. |
| 17:29 | <Krinkle> | We've dropped support for IE6 and IE7 in 2014 |
| 17:29 | <JonathanNeal> | Oh good. |
| 17:30 | <Krinkle> | for JS runtime at least (we "support" that fact that it isn't supported by cutting the mustard) |
| 17:30 | <Krinkle> | We still support them for basic stylesheet and content accessibility |
| 17:30 | <Krinkle> | Because IE is very UX intrusive when it comes to exceptions. |
| 17:31 | <annevk> | Krinkle: removed, let me know if you need it back or want to work on something else |
| 17:31 | <Krinkle> | JonathanNeal: It's been a while since I evaluated Android usage though. Let me take a peek |
| 17:32 | <Krinkle> | JonathanNeal: This is last month's Wikimedia global page-view traffic browser usage: https://docs.google.com/spreadsheets/d/1n9FhSqcBGM9iKXrlHsP0EZI0gU89Rmz5m51uglUGVjs/edit#gid=0 |
| 17:35 | <Krinkle> | Traditionally our cut off for dropping support is about 0.1% |
| 17:35 | <Krinkle> | that's up form 0.01% in 2005. We've become laxer and more willing to drop support. Mostly because we now have a more mature non-js mode. |
| 17:39 | <Krinkle> | Looks like Android 2 is at 0.69% (109M views in August '15) |
| 17:51 | <Krinkle> | JonathanNeal: So back to the load promise, I think I'll just bite the bullet and try and ship this as part of the first script payload (which runs before window onload for sure) |
| 17:52 | <JonathanNeal> | The one from your gist? |
| 17:52 | <Krinkle> | And have it be defined as window.onload ->setTimeout->resolve. |
| 17:52 | <Krinkle> | Can't use readystatechange because Android 2.3. And I don't see any way to determine whether readyState=complete in Android |
| 17:52 | <Krinkle> | it only implements the non-standard readyState "loaded" which an equivelant to "interactive" |
| 17:53 | <Krinkle> | in Android the current code in the gist just remained unresolved. |
| 17:54 | <JonathanNeal> | What about using the window.onload event then? |
| 17:54 | <Krinkle> | Well, I can only do that if it hasn't happend yet |
| 17:54 | <Krinkle> | I don't have a way to determine whether it has |
| 18:00 | <JonathanNeal> | Unrelated, these new CSS syntax goodies like `@nest` rules, `:matches`, and `@apply` really chip away at the usability of Sass. |
| 18:00 | <TabAtkins> | That's the point, yeah. |
| 18:01 | <TabAtkins> | Preprocessors exist largely because CSS hasn't been extensible. As we fix that, the set of things that preprocessors provide will shrink. |
| 18:01 | <TabAtkins> | They'll still be useful, just not for a bunch of basic stuff, as we'll be able to move those into either core CSS or at least small JS libraries. |
| 18:02 | <gsnedders> | Does JS really make more sense than preprocessing the CSS? |
| 18:08 | <Domenic> | annevk: oh, I thought you already duped all of them. But I guess not the issues. Seems reasonable, although I personally find it satisfying when my commit message contains a nice long string of "Fixes #123. Fixes #124. Fixes #231." :) |
| 18:09 | <TabAtkins> | gsnedders: It's easy than a build step. That's basically ReSpec's value proposition over Bikeshed. |
| 18:11 | <gsnedders> | All my current fun with CSS is mostly down to prefixes, different browsers supporting different stuff in short-hands, and other fun with legacy browsers. |
| 18:11 | <gsnedders> | I don't even know how to fix most of that, precicely because legacy. |
| 18:29 | <Domenic> | This fetch change is so good, look at all this extra precision being added. |
| 18:36 | <wanderview> | I wish I had time to review the fetch change |
| 19:00 | <Krinkle> | Hm.. interesting. So the pre* specs are together now in resource-hints. That's a nice simplification. |
| 20:37 | <zcorpan> | Domenic: annevk: ok i've looked through the fetch PR editorially. i'd also like to review that there isn't something in the old text that is lost, which is non-obvious |