02:06
<JonathanNeal>
Hey, give or take 697.
08:11
<annevk>
Domenic: one more look? https://github.com/whatwg/html/pull/187
08:18
<annevk>
MikeSmith: attempted an answer of sorts
08:25
<annevk>
roc: Yeah, very interesting indeed. Also how mobile app development you need to be much more correct before release, due to bugs leading to crashes.
08:26
<Domenic>
annevk: I can't actually find the definition for #concept-WorkerGlobalScope-url ?
08:26
<annevk>
Domenic: directly below WorkerGlobalScope</dfn>
08:27
<annevk>
Domenic: "A WorkerGlobalScope object has an associated url (null or a URL). It is initially null."
08:27
<annevk>
Domenic: but the data-x stuff gets lowercased
08:27
<annevk>
Domenic: so #concept-workerglobalscope-url
08:28
<Domenic>
Ah OK
08:29
<annevk>
Domenic: so yeah, I'm pretty sure we need <script type=module> to require CORS, due to new SOP risks, but folks are sensitive
08:30
<Domenic>
annevk: it seems better to me to follow CORS on all new things.
08:30
<Domenic>
<script type="module"> should mostly be used for inline anyway, IMO.
08:30
<Domenic>
But I guess the question recurs for absolute-URL `import`s
08:30
<annevk>
Domenic: yeah, I think we cannot not require CORS
08:30
Domenic
is in European timezone for a few days
08:30
<annevk>
Domenic: not sure what to default to though
08:31
<annevk>
Domenic: I guess "anonymous"
08:42
<Domenic>
Hmm I wonder if http://www.w3.org/TR/cors/ should go in https://wiki.whatwg.org/wiki/Fork_tracking ?
08:42
<annevk>
Domenic: s/the/this/ would no longer be consistent with the definition for self
08:43
<annevk>
Domenic: we really need an IDL-defined "this"
08:43
<annevk>
Domenic: yeah I guess it should
08:43
<annevk>
Domenic: that's been causing a ton of confusion
08:43
<annevk>
Domenic: I will add it
08:43
<Domenic>
annevk: acknowledged on s/the/this
09:15
<nox>
annevk: Talking about WebIDL, https://github.com/heycam/webidl/pull/58
09:19
<MikeSmith>
annevk: thanks (for the SO answer)
09:21
<annevk>
nox: you want heycam|away
09:28
<annevk>
Okay shit, I accidentally force pushed html-build
09:29
<annevk>
Can someone undo?
09:29
<annevk>
And then enable protection for master?
09:29
<annevk>
MikeSmith: Domenic: ^^
09:32
<annevk>
MikeSmith: Domenic: unless there were commits after zcorpan's commit, nothing may have been damaged
09:43
<MikeSmith>
annevk: will take a look, and no worries, I'm sure we can unwind it if needed
09:43
<MikeSmith>
but yeah, will set up master-branch protection there right now
09:44
<MikeSmith>
btw is anything I wrote at http://stackoverflow.com/a/32769242/441757 not accurate?
09:44
<Domenic>
annevk: yeah can fix, although my Linux computer is back at the hotel so will be a few hours.
09:45
<MikeSmith>
(about non-localhost web apps being able to read from local file:// URLs)
09:45
<annevk>
MikeSmith: Domenic: I'll just not touch anything there for now
09:46
<MikeSmith>
Domenic: I'll just wait for you to reset it, unless you want me to deal with it in the mean tiem
09:46
<Domenic>
MikeSmith: if you have the latest commits locally then go ahead.
09:47
<MikeSmith>
k looking now
09:47
<nox>
annevk: Yes, but as you say he is away. :)
09:50
<MikeSmith>
Domenic: so yeah the last merge to master was for https://github.com/whatwg/html-build/pull/35 and I have that of course, so I reckon you got the same on your other machine
09:50
<MikeSmith>
so I'll go ahead and force-push from my clone
09:50
<Domenic>
Shouldn't need force, right?
09:50
<MikeSmith>
ah yeah
09:51
<Domenic>
But yeah I am 95% sure that was HEAD.
09:51
<MikeSmith>
yeah same here
09:52
<MikeSmith>
and if we're wrong and there was some other change we're forgetting about that happened in the mean time, you can push it later
09:52
<MikeSmith>
I definitely didn't push to master myself since then
09:53
<MikeSmith>
ok, just pushed (and yeah, didn't need to force-push it), and it was just that one change since the time of zcorpan's commit
09:54
<annevk>
MikeSmith: enable protection?
09:54
<MikeSmith>
yup, just did now
09:55
<MikeSmith>
so all is now right with the world again
09:55
<annevk>
sorry about that
09:55
<annevk>
glad things are still a bit distributed, even though GitHub is not
09:55
<MikeSmith>
yeah
11:21
<smaug____>
annevk: could "9.5.4 Broadcasting to many ports" be possibly removed from the spec
11:23
smaug____
files a bug
11:39
<MikeSmith>
fyi I just now added a deprecation warning to https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache
11:40
<MikeSmith>
I guess it should be added to all other MDN pages for appcache
11:43
<MikeSmith>
what's the release date for Firefox 42?
11:43
<MikeSmith>
beginning of November? middle?
11:43
MikeSmith
finds http://release.mozilla.org/planning/2015/01/13/release-schedule.html
11:44
<MikeSmith>
2015-11-03
11:44
<botie>
2001
11:45
<Ms2ger>
Thank you botie
11:46
<MikeSmith>
yeah I got no idea what "feature" of botie produced that, but I approve
11:46
<MikeSmith>
botie++
11:47
<smaug____>
https://wiki.mozilla.org/RapidRelease/Calendar
11:48
MikeSmith
looks
11:50
<MikeSmith>
oh geez I only now realize that botie is just doing simple subtraction there. that makes it much less interesting. I guess I had thought it was just picking some number at randome
11:50
<Domenic>
hahaha
11:50
<MikeSmith>
thanks smaug____
11:50
<Domenic>
botie is so endearingly dumb
11:50
<MikeSmith>
hah
11:50
<MikeSmith>
yeah
11:52
<zcorpan>
1-2
11:52
<zcorpan>
:-|
12:01
<MikeSmith>
zcorpan: you gotta tell it the right way :p
12:02
<zcorpan>
2015-11-2500
12:02
<botie>
-496
12:04
<zcorpan>
2015-11-66000
12:04
<botie>
-63996
12:04
<Domenic>
=1-2
12:04
<Domenic>
1-2=?
12:04
<zcorpan>
2015-11-4294967296
12:04
<botie>
-4294965292
12:04
<Domenic>
uh oh
12:05
<zcorpan>
2015-2016-4294967296
12:05
<botie>
-4294967297
12:07
<Ms2ger>
Kiddos... :)
12:08
<zcorpan>
1-2-9007199254740992
12:08
<botie>
-9007199254740993
12:08
<zcorpan>
impressive
12:08
<zcorpan>
python?
12:11
<zcorpan>
next up, consume all for botie's RAM with a big number :-)
12:12
<Ms2ger>
Anyone harassing bots shall be punished :)
12:17
<zcorpan>
no chocolate? :-(
12:21
<Ms2ger>
TabAtkins, wanna define @import in terms of Fetch?
13:21
<MikeSmith>
annevk: FYI about the MDN SRI page, after talking with Francois I'm going to drop the Fetch-related bits there for now, and plan to re-add them later if/when they get re-added to the SRI spec
13:22
<MikeSmith>
(in light of https://github.com/w3c/webappsec/pull/460 「SRI: remove "Fetch Modifications" section」)
13:26
<MikeSmith>
gsnedders: does html5lib work under Python 3?
13:28
<Ms2ger>
I think it should
13:29
<MikeSmith>
ok
13:29
<MikeSmith>
I figured it did but wasn't sure
14:20
<annevk>
MikeSmith: well, fetch() will remain working for SRI
14:21
<annevk>
MikeSmith: I guess the question is whether the MDN page should reflect the spec or the feature
14:21
<annevk>
MikeSmith: I'd think the latter, personally
14:22
<MikeSmith>
annevk: it doesn't work in gecko yet, right? and I think Francois has found that it doesn't work yet in blink either
14:22
<MikeSmith>
and he's dropping it from the SRI spec for now
14:22
<MikeSmith>
that's what the PR does, right?
14:22
<annevk>
MikeSmith: no, the PR just reflects changes in Fetch
14:23
<MikeSmith>
oh ok
14:23
<annevk>
MikeSmith: integrity for fetch() is defined by Fetch
14:23
<MikeSmith>
ah yeah OK
14:23
<annevk>
MikeSmith: and we should define integrity for <link> and <script> in HTML, really
14:23
<MikeSmith>
yeah
14:23
<MikeSmith>
OK
14:26
<annevk>
smaug____: you know you can submit PRs, right? ;-)
14:26
<smaug____>
github...
14:27
<smaug____>
I could write a patch I guess
14:27
<annevk>
smaug____: it's a magical place
14:27
smaug____
wonders how to attach patches to github
14:27
<smaug____>
I guess it is somehow possible
14:27
<annevk>
smaug____: I'm happy to do it for you
14:27
<annevk>
smaug____: didn't realize you hadn't worked with PRs at all yet
14:28
<smaug____>
I'm very old school
14:28
<smaug____>
ancient beast
14:29
<annevk>
from a children's fairy tale, right?
14:30
<smaug____>
I don't count any Tolkien's Middle-earth related work as children's fairy tale, just fairy tale ;)
14:31
<annevk>
I suppose, I thought the Hobbit was meant for children, but it's entertaining either way
14:32
<smaug____>
(sure, it was was probably written for children, but sort of turned out to be also something else)
14:34
<smaug____>
annevk: actually I just noticed that PortCollection stuff again while reading about MessagePorts. I wonder how often MessagePorts are actually sent to some other window/worker after they've been started.
14:35
<annevk>
smaug____: not sure, I think baku has been fixing some of that stuff
14:35
<smaug____>
IMO the current setup is overengineered, but most probably too late to change
14:35
<smaug____>
yeah, baku implemented MessagePorts
14:35
<smaug____>
I'm thinking about the spec
14:36
<annevk>
smaug____: you mean we should just have had simple message passing and no channels and all that?
14:36
<smaug____>
because jesup was asking about making DataChannel transferable
14:36
<annevk>
cloneable or transferable?
14:36
<smaug____>
annevk: well, at least once a MessagePort is started, is there any good use case to transfer it?
14:37
<smaug____>
annevk: transferable
14:37
<annevk>
smaug____: I think Hixie had some use cases around services
14:37
<smaug____>
you'd get RTCDataChannel probably in the main thread and transfer it to some worker
14:37
<annevk>
smaug____: but it's been a while since I tried to look into that and it was probably too complicated for me anyway
14:38
<smaug____>
so I wonder if RTCDataChannel could actually have some tiny bit simpler setup
14:38
<smaug____>
oh well, I'll let jesup to sort this out
14:47
<TabAtkins>
Ms2ger: Yes I do.
14:50
<TabAtkins>
roc: Ugh, sites like that are a stark example of why you should never give sites the ability to control scroll directly. The momentum is all fucked up and it really messes with me. >_<
15:34
<aleray>
Hi, I have this piece of code using html5lib-python: http://dpaste.com/2WEDB88
15:34
<aleray>
do you know why I get `u'<p>Des outils sensibles'` instead of `u'<p>Des outils sensibles</p>'`
15:34
<aleray>
?
15:41
<aleray>
ok sorry I should have searched a little bit more before asking: http://stackoverflow.com/questions/9107649/what-is-going-on-with-this-html5lib-script
16:02
<annevk>
JakeA: https://github.com/whatwg/fetch/issues/106#issuecomment-142218051
16:39
<annevk>
The WebSocket plot thickens
16:39
<Hixie>
lordy now what
16:39
<annevk>
Hixie: hey!
16:40
<annevk>
Hixie: nothing much, just trying to figure out HSTS/upgrade-insecure-requests/MIX for WebSocket in the face of the IETF not updating the spec
16:40
<annevk>
Hixie: https://github.com/whatwg/html/issues/180 has ramblings
16:41
<Hixie>
websocket is unaffected by hsts in theory. it's not http.
16:41
<annevk>
In practice it seems it kinda is
16:41
<annevk>
I very much expect that in browsers they go in the same Fetch pipeline as everything else
16:42
<Hixie>
figures
17:24
<Hixie>
abarth: https://github.com/flutter/engine/pull/1344
17:52
<abarth>
Hixie: https://github.com/flutter/engine/pull/1345 <--- moar tests
18:28
<abarth>
Hixie: https://github.com/flutter/engine/pull/1346 <--- MOAR tests
18:29
<terinjokes>
does SRI make sense for scripts being served from your own domain (with TLS)?
18:30
<terinjokes>
seems like all the example are for loading content from CDNs
20:03
<MikeSmith>
terinjokes: I think it might if you have some shared hosting setup where users might be able to overwrite other users scripts (either inadvertently or maliciously)
20:05
<MikeSmith>
or even if were on the same system working, and, e.g., you have some document that wants version X of some script and I have some document that wants version Y
20:05
<MikeSmith>
and we want to make sure versions are accidentally getting overwritten
20:07
<MikeSmith>
so I guess it can also just be an additional level of integrity checking that you might want to have regardless of where you're hosting the scripts
20:08
<JonathanNeal>
Sometimes I want to do something like `:root { font-size: 6.25%; }`, just so that 1rem = 1px so I can mark things up using similar numbers, but differentiate when I think the element should grow or shrink based on the font size.
20:38
<terinjokes>
MikeSmith: i got a ticket to implement version fingerprinting/cache busting, was thinking that I just compute (and use) SRI, and just take some subset of the hash as the bust
20:42
<MikeSmith>
terinjokes: sounds workable
20:42
<terinjokes>
gracias
20:43
<terinjokes>
no plans to allow other users to modify the page, but who knows
20:43
<terinjokes>
ensuring we're delivering the right version is a nice addition though
20:52
<SimonSapin>
Do browsers run html5lib tests?
20:55
<MikeSmith>
SimonSapin: I believe Mozilla CI does, right?
20:56
<MikeSmith>
via wpt
20:56
<MikeSmith>
because they are incorporated into the wpt repo
20:57
<MikeSmith>
SimonSapin: https://github.com/w3c/web-platform-tests/tree/master/html/syntax/parsing
20:58
<MikeSmith>
the htmllib_*html files
21:07
<SimonSapin>
MikeSmith: I’m trying to get the history right to explain html5lib vs libxml2 (lxml.html) in a blog post
21:07
<SimonSapin>
also, https://github.com/SimonSapin/html5ever-python :)
21:09
<SimonSapin>
MikeSmith: is it fair to call html5lib a reference implementation developed alongside the HTML parsing spec?
21:10
<MikeSmith>
yes
21:10
<MikeSmith>
it is fair to say that
21:10
<MikeSmith>
it was the first implementation of the parsing algorithm
21:11
<MikeSmith>
ah nice to have the Python bindings for html5ever
21:11
<MikeSmith>
SimonSapin: and yeah it absolutely was developed alongside the parsing spec
21:11
<MikeSmith>
jgraham and gsnedders could give you more of the history
23:17
<jgraham>
SimonSapin: It isn't a true reference implementation; if it disagrees with the spec then the spec is right and the implemenation is wrong. But one goal was certainly to help with the development of the spec.
23:18
<SimonSapin>
fair enough