01:11
<MikeSmith>
forgot the quotation marks around that
01:12
<MikeSmith>
also around "grateful" and "help"
01:12
<MikeSmith>
http://stackoverflow.com/questions/34580598/how-to-add-javascript-to-custom-elements
07:47
<annevk>
it seems krijn is no longer in this channel but that could be used as quote somewhere "prestigious open source community"
08:55
<JakeA>
annevk: https://fetch.spec.whatwg.org/#http-fetch 5.redirect.10.4 - should the body of the request be removed when the method is changed from POST to GET?
08:56
<annevk>
JakeA: yeah I guess so
08:56
<annevk>
JakeA: and it should probably impact streams at some point in some unknown way
08:57
<JakeA>
annevk: I'll file a bug. I think Chrome tries to create a GET-with-body at this point & falls over, but haven't confirmed
08:57
<annevk>
JakeA: ooh 😟 hope that's not my fault
08:58
<JakeA>
annevk: ALL YOUR FAULT (nah, sounds like something we should have had a test for and spotted earlier)
09:02
<JakeA>
annevk: https://github.com/whatwg/fetch/issues/187
09:10
<JakeA>
Can't recreate the Chrome issue though
09:21
<JakeA>
Ah, yes I can, but it's not related to that bit of the spec
10:56
<annevk>
zcorpan: I rebased https://github.com/whatwg/dom/pull/120 the other day
10:56
<annevk>
zcorpan: hope that's okay
10:56
<zcorpan>
annevk: sure
11:00
<zcorpan>
Domenic: yt?
11:01
<zcorpan>
wondering about https://github.com/whatwg/html-build/issues/42
11:13
<annevk>
zcorpan: perhaps fred-wang can ask the reviewers to weigh in?
11:43
<annevk>
MikeSmith: now that we have directories we can probably start removing the leading dots from the build files?
11:44
<MikeSmith>
annevk: yeah
14:37
<zcorpan>
annevk: for <script type=module>, what is the difference between <track>-like and fetch()-like when omitting crossorigin attribute and fetching a same-origin resource? does the latter require CORS headers?
14:38
<annevk>
zcorpan: the latter does not include credentials
14:38
<annevk>
iirc
14:39
<zcorpan>
annevk: what about handling the response if it has no CORS response headers?
14:42
<annevk>
zcorpan: same-origin doesn't require CORS, unless there's a cross-origin redirect inbetween, but you can't get there when mode is same-origin
14:44
<zcorpan>
annevk: context for my question is https://github.com/whatwg/html/pull/443#discussion_r48679260 where he suggests mode = "cors" for omitted attribute
14:45
<annevk>
zcorpan: I think we could probably change the default for <track> and EventSource to just be "cors" rather than "same-origin"
14:46
<annevk>
zcorpan: I think Hixie required the crossorigin="" attribute for clarity that CORS was required
14:46
<annevk>
zcorpan: I guess if we change that with <script type=module> (defaulting to requiring CORS) we could change it elsewhere too over time
14:49
<zcorpan>
annevk: ok, maybe so. but i think it'd be bad if <track> or <script type=module> resulted in network error when trying to fetch a CORS-unaware same origin url
14:49
<annevk>
zcorpan: as I said, that wouldn't happen
14:50
<zcorpan>
good then :-)
14:51
<annevk>
zcorpan: basically, "same-origin" means you cannot go cross-origin, "no-cors" means you can go anywhere, "cors" means that once you go cross-origin, CORS headers are required every step of the way, but before that it's the same as "same-origin"
14:53
<zcorpan>
annevk: thx
15:08
<MikeSmith>
annevk: so about the "was built for newer OSX version (10.11) than being linked (10.4)" warnings when building wattsi: They go way if you install the fpc 3.0.0 stable release from ftp://freepascal.stack.nl/pub/fpc/dist/3.0.0/i386-macosx/ (rather than the pre-release)
15:08
<MikeSmith>
I'll update the wattsi README.md
15:08
<MikeSmith>
zcorpan: ⬆
15:09
<zcorpan>
MikeSmith: ty
15:11
<nox>
MikeSmith: I applaud your appropriate use of emoji.
15:18
<MikeSmith>
nox: that appropriateness was unintentional 😆
15:18
<nox>
Hah.
15:30
<zcorpan>
nice, now i can write a recipe in just a few characters. http://blog.unicode.org/2015/05/unicode-90-candidate-emoji.html
15:40
<Ms2ger>
U+1F922
15:43
<smaug____>
kind of awkward to see Chrome warn about use of deprecated APIs when browsing some Google web sites
16:49
<annevk>
MikeSmith: oh cool, stable is alright?
16:49
<annevk>
MikeSmith: so how do you remove the non-stable version?
16:55
<nox>
smaug____: It's also weird to get them because you looked at NodePrototype.
16:55
<smaug____>
hmm
16:56
<smaug____>
oh, I see
16:58
<gsnedders>
Anyone remember why we introduced @srcdoc on iframe?
16:58
<gsnedders>
Like, why not just use data URIs?
17:00
<smaug____>
(there was some reason, but I never understood it)
17:02
<gsnedders>
(I was assuming we didn't just do it for no reason. :))
17:03
<annevk>
srcdoc is same-origin iirc and requires escaping less code points
17:03
<smaug____>
data urls for iframes are same origin
17:03
<gsnedders>
smaug____: only in some UAs, AFAIK
17:06
<smaug____>
ah, right, data urls are a mess
17:07
<gsnedders>
I had the impression that it was starting to seem like we would try and make data URLs other-origin everywhere, but idk
17:13
<annevk>
that is indeed the plan gsnedders
17:43
<TabAtkins>
It was mainly the "requires less escaping", because srcdoc requires *no* escaping at all (save the < and & if you want to avoid data corruption, but skipping that isn't a security risk).
17:44
<TabAtkins>
You can literally just XHR a doc off the network, assign it to iframe.srcdoc, and you're done.
17:45
<TabAtkins>
(Intended to improve the security properties of <iframe sandbox> for use in rendering comments by making it easier to not fuck up.)
21:58
<MikeSmith>
annevk: about wattsi you don't need to remove the previous version. Just get the ftp://freepascal.stack.nl/pub/fpc/dist/3.0.0/i386-macosx/fpc-3.0.0.intel-macosx.dmg image and open it and run the installer and it will overwrite all the files the unstable version installed.