| 04:16 | <MikeSmith> | TabAtkins: yeah I agree it would help for Fetch to have an explainer section. I guess I can make an attempt to write one myself if nobody else beats me to it |
| 07:51 | <annevk> | MikeSmith: TabAtkins: I missed the context for this, but I agree Fetch could use more language here |
| 07:52 | <annevk> | MikeSmith: TabAtkins: I always find it a little hard to justify working on such things while there's still a ton of incorrect implementer language around |
| 08:14 | <annevk> | I have a hard time not reading https://github.com/whatwg/dom/issues/102 as "Make Attr great again" |
| 11:29 | <nox> | annevk: That issue makes me very sad. :( |
| 11:58 | <zcorpan> | can we also disable features when document.write is used? :-D |
| 12:05 | <jgraham> | maybe we could just disable loading webpages when document.write is used :) |
| 12:06 | <jgraham> | Although the servo people claim that not supporting document.write is a zero-cost ad-blocker |
| 12:06 | <jgraham> | (this is not really true) |
| 14:21 | <smaug____> | ok, so I wonder how many specs are now inconsistent with http://w3c.github.io/webappsec-mixed-content/ :/ |
| 14:21 | <smaug____> | this is a great mess atm |
| 14:21 | <smaug____> | oh well |
| 14:21 | <smaug____> | such is life :) |
| 14:22 | <MikeSmith> | solution: just set Content-Security-Policy: upgrade-insecure-requests and forget it |
| 14:23 | <annevk> | smaug____: only WebSocket is |
| 14:23 | <annevk> | smaug____: everything else should route through Fetch already which dispatches to that specification |
| 14:24 | <smaug____> | one day I'll read Fetch spec |
| 14:24 | <annevk> | smaug____: soon WebSocket will also route through Fetch and things will be wonderful |
| 14:24 | <annevk> | maybe not wonderful, but slightly better anyway |
| 14:24 | <smaug____> | so how is http://w3c.github.io/webappsec-mixed-content/ related to this all then? |
| 14:25 | <annevk> | smaug____: Fetch uses that specification to define the Mixed Content check |
| 14:25 | <annevk> | smaug____: step 5 of https://fetch.spec.whatwg.org/#main-fetch |
| 14:26 | MikeSmith | misunderstood; thought smaug____ was talking about the resources of the spec source |
| 14:28 | <smaug____> | MikeSmith: nah, just trying to figure out how many specs I need to review before reviewing a patch. |
| 14:28 | <smaug____> | looks like 3 |
| 14:41 | <MikeSmith> | well that seems manageable |
| 14:47 | <annevk> | zcorpan_: if you want I can introduce such a default User-Agent value concept now |
| 14:47 | <annevk> | zcorpan_: I mean, I'll do it unless you see a problem |
| 14:47 | <zcorpan_> | annevk: sure |
| 14:47 | <MikeSmith> | today’s SO question where somebody had a problem that turned out to be due just to them not knowing that Fetch doesn’t send credentials by default http://stackoverflow.com/questions/35868312/django-1-9-ajax-form-csrf-token-403-error-csrf-cookie-not-set/35869947#35869947 |
| 14:48 | <annevk> | MikeSmith: yeah, this safe default is tripping up many folks |
| 14:48 | <annevk> | MikeSmith: maybe I should've used XHR's default... so little feedback during the development of that API |
| 14:50 | <MikeSmith> | annevk: I think partly it just takes time for it to enter into the collective developer consciousness |
| 14:51 | <MikeSmith> | I mean, there are many more arcane/esoteric things about the platform that developers just sorta know |
| 14:51 | <annevk> | MikeSmith: hopefully, I know Mark Miller will be pleased with this default, although not everyone will see that as a good sign |
| 15:41 | <Ms2ger> | annevk, what's the "local-URLs-only flag" for? |
| 15:42 | <annevk> | Ms2ger: CSS/SVG |
| 15:43 | <annevk> | Ms2ger: they haven't really defined their fetching model yet, though, but this is what I think they'll need to define "SVG as image" and "SVG as gradient" and such |
| 15:43 | <annevk> | Ms2ger: although maybe they're a little closer now, but nothing to the level of detail I'd like |
| 15:43 | <Ms2ger> | I see, thanks |
| 15:45 | <Ms2ger> | annevk, is there a reason not to return the network error in step 2 of https://fetch.spec.whatwg.org/#concept-main-fetch ? |
| 15:52 | <annevk> | Ms2ger: yeah, async callers wouldn't know what happened |
| 15:53 | <Ms2ger> | Still trying to figure the control flow here |
| 15:55 | <annevk> | Ms2ger: main fetch returns for recursive and synchronous invocations; for async it ends up queuing stuff in the end |
| 15:56 | <annevk> | Ms2ger: it's not the best and I've tried to get input on the design, but as with most things I write I'm kinda left to figure it out on my own |
| 15:56 | <Ms2ger> | Yeah |
| 15:56 | <annevk> | Ms2ger: not sure if that's due to me or simply a result of the problems I tackle not being super interesting to others |
| 15:57 | <Ms2ger> | Or designing stuff like this being Hard(TM) :) |
| 15:58 | <annevk> | wanderview: oooh I see |
| 15:58 | <annevk> | wanderview: you'd wait all the way until the network |
| 15:58 | <wanderview> | yea, that was the idea |
| 15:59 | <wanderview> | try to make all the credential stuff work the same |
| 15:59 | <annevk> | wanderview: network or cache API? |
| 15:59 | <annevk> | wanderview: otherwise you're in trouble offline |
| 15:59 | <wanderview> | well, cookies don't go in cache API requests now |
| 15:59 | <annevk> | wanderview: no, but they get stored somewhere |
| 16:00 | <annevk> | wanderview: I guess these get stored too someplace |
| 16:00 | <wanderview> | I would have to think about Cache a bit |
| 16:00 | <annevk> | it might be fine, given that there is a credential store |
| 16:00 | <wanderview> | annevk: yea, but the cookie connection to the Request is automatic... here script is attaching the Credential object |
| 16:01 | <wanderview> | and that association of the Credential to Request should happen at constructor time |
| 16:01 | <annevk> | I think you might still want to pass it to request somehow and request might want to identify it will get those things attached |
| 16:01 | <annevk> | yeah |
| 16:01 | <annevk> | but it sorta makes sense to not do it straight away to avoid a bunch of the pitfalls |
| 16:01 | <wanderview> | annevk: I'll write some github issues this afternoon so mikewest can see them |
| 16:01 | <annevk> | sounds good |
| 16:43 | <Domenic> | annevk: want to wait for another look from aklein or shall I sanity-check compile and merge the structured clone fix? |
| 17:13 | <annevk> | Domenic: happy to wait |
| 17:36 | <Domenic> | annevk: turned out "create an element" was a really good idea, if only for deduping code between createElement and createElementNS. So yay. |
| 17:37 | <annevk> | Yay abstractions |
| 17:40 | <wanderview> | annevk: https://github.com/w3c/webappsec-credential-management/issues/11 |
| 18:08 | <Domenic> | Why are we passing attribute namespace to attributeChangedCallback. It's so useless. |
| 18:30 | <smaug____> | Domenic: consistency with MutationObserver? |
| 18:30 | <smaug____> | just a guess |
| 18:36 | <Domenic> | smaug____: seems legit |
| 19:40 | <aklein> | Domenic, annevk: structured clone fix looks good now |
| 20:30 | <annevk> | aklein: ta, landed |
| 20:31 | <annevk> | aklein: I guess now we can work on the serialize/deserialize rewrite -_- |
| 20:50 | wanderview | writes the promise-returning withFrame(url) function a lot too... |
| 22:23 | <Domenic> | Starting to feel like the custom elements spec is something we can be proud of... |
| 22:24 | <Domenic> | Big remaining issues are nanotasks and parser |
| 22:26 | <Domenic> | https://github.com/w3c/webcomponents/issues/412#issuecomment-193935169 is also interesting, should be pretty easy once we figure out what we want though |