2015-09-01
[17:10:17.0000] <Domenic>
Wheee OK nobody needs to install FreePascal anymore https://github.com/domenic/wattsi-server

[17:10:33.0000] <Domenic>
(Although I'm pretty sure as of this morning everyone already did, lol.)

[17:28:20.0000] <MikeSmith>
/me looks

[17:29:11.0000] <MikeSmith>
wow

[17:29:13.0000] <MikeSmith>
nice

[17:29:58.0000] <MikeSmith>
Domenic: you gonna work on a patch to make the build use this, or do you want me to?

[17:30:18.0000] <Domenic>
MikeSmith: already done :) https://github.com/whatwg/html-build/pull/10

[17:30:42.0000] <MikeSmith>
dang

[17:30:44.0000] <Domenic>
MikeSmith: but error handling is annoying... https://superuser.com/questions/965558/get-curl-to-output-non-2xx-to-stderr-but-2xxs-to-a-file

[17:30:51.0000] <MikeSmith>
/me looks

[17:30:57.0000] <Domenic>
MikeSmith: still counting on you for the separate-directories patch though!

[17:31:26.0000] <MikeSmith>
OK yeah will do that

[17:32:04.0000] <MikeSmith>
Domenic: about that superuser question, we should talk to Daniel

[17:32:12.0000] <MikeSmith>
about curl

[17:32:21.0000] <MikeSmith>
he works a Mozilla now, right?

[17:32:39.0000] <MikeSmith>
Daniel Stenberg

[17:37:54.0000] <Domenic>
Yeah people on Twitter are referring me to him

[17:38:16.0000] <Domenic>
I feel kind of bad bugging the creator of a program on usage info though, especially for something that popular

[17:43:49.0000] <MikeSmith>
dunno, he seems to be pretty enthusiastic about helping people solve problems

[17:44:09.0000] <MikeSmith>
and if it were any easy problem you'd already have an answer

[17:46:00.0000] <Domenic>
well a couple people pinged him so we'll see what happens

[18:15:43.0000] <MikeSmith>
ok

[19:18:15.0000] <Domenic>
I think @WHATWG should retweet https://twitter.com/mnot/status/638532265388019712

[19:19:03.0000] <Domenic>
Also MikeSmith I am 90% sure https://twitter.com/domenic/status/638531133274132481 will work, woo.

[19:22:52.0000] <MikeSmith>
Domenic: awesome

[19:25:20.0000] <MikeSmith>
Domenic: heh, that mnot tweet is nice too

[19:25:32.0000] <MikeSmith>
mnot, you have been assimilated

[21:07:54.0000] <SimonSapin>
hsivonen: http://w3techs.com/technologies/details/en-utf16/all/all sees less than 0.007% of websites using UTF-16. Do we have telemetry on this? Do we have a threshold for dropping support of things?

[21:08:16.0000] <annevk>
Domenic: retweeted

[21:36:26.0000] <Domenic>
There is still a lot of low-hanging fruit

[21:40:26.0000] <annevk>
Yeah, I was going to fix base URLs but that's harder than expected

[21:52:01.0000] <Domenic>
here is one minor tweak we made, https://github.com/tmpvar/jsdom/blob/master/lib/jsdom/living/helpers/document-base-url.js especially https://github.com/tmpvar/jsdom/blob/master/lib/jsdom/living/helpers/document-base-url.js#L34

[22:35:00.0000] <Sebmaster>
annevk: i think i have another issue with the url spec :/

[22:35:13.0000] <Sebmaster>
you have a minute?

[23:00:28.0000] <annevk>
Sebmaster: sure

[23:01:38.0000] <Sebmaster>
Awesome!

[23:02:42.0000] <Sebmaster>
Okay so, assume we have an object with mixed in urlutils. it calls set the input with some string as input, let's go with "example"

[23:03:16.0000] <annevk>
Sebmaster: hmm so URLUtils has open issues

[23:03:22.0000] <annevk>
but okay

[23:03:35.0000] <Sebmaster>
So set the input parses the stuff, calls get the base etc. and comes up with some resulting url: http://example.org/example

[23:04:06.0000] <Sebmaster>
so we have an object, its input is set to example, and its url is set to http://example.org/example

[23:05:38.0000] <annevk>
Sebmaster: yes

[23:05:41.0000] <Sebmaster>
we now call the hash attribute setter with a string "foobar", it does the whole parsing spiel again, we get a resulting object: input is "example", url is "http://example.org/example#foobar"

[23:07:09.0000] <Sebmaster>
when we now call the href attribute getter, it calls reset the input, which in turn calls set the input with "example" and "http://example.org/example#foobar"

[23:07:47.0000] <Sebmaster>
set the input then sets input and url, but since input is non-null, it then re-parses the url with input, resulting in #foobar being dropped

[23:10:12.0000] <Sebmaster>
and i really, really hope i didn't miss any part of the spec again :S

[23:13:03.0000] <annevk>
Sebmaster: no you didn't

[23:13:24.0000] <annevk>
Sebmaster: the problem is that once you set the hash attribute the input also needs to be updated

[23:14:00.0000] <annevk>
Sebmaster: I fixed URLUtils the wrong way and I haven't really worked on specifying it in the right way yet since I didn't have access to update HTML directly, where we should probably put some of the logic

[23:14:25.0000] <Sebmaster>
thank god, i was getting worried i'm constantly misreporting everything

[23:14:49.0000] <Sebmaster>
well then, I'll wait until you're done with the new changes

[23:20:12.0000] <annevk>
Sebmaster: https://github.com/whatwg/url/issues/62 and https://github.com/whatwg/url/issues/61

[23:20:17.0000] <annevk>
Sebmaster: it's quite the mess :-(

[23:25:44.0000] <Sebmaster>
Oh right, those tie into the whole thing

[23:26:37.0000] <Sebmaster>
I assumed the spec would be in a working state without those reworks :(

[23:27:30.0000] <Sebmaster>
Means I can put it off again though, so that's fine for me for now :D

[23:27:55.0000] <annevk>
Maybe I should add a note to the API since it'll take me a couple of weeks before I'm going to get to that I think

[23:30:21.0000] <annevk>
Done

[23:47:34.0000] <annevk>
MikeSmith: I had it happen again that a link to source became source

[23:49:44.0000] <annevk>
Locally building is pretty much a must it seems, looking forward to somebody making it faster

[00:06:38.0000] <MikeSmith>
annevk: is it just the symlink to the `source` file that happens with? or others too?

[00:07:05.0000] <annevk>
MikeSmith: I haven't tested the others, they're mostly static so it doesn't matter

[00:07:46.0000] <MikeSmith>
ok

[00:09:12.0000] <MikeSmith>
well *grumble grumble* we wouldn't have a problem at all with that if we just moved the build tools into the html repo

[00:10:28.0000] <annevk>
MikeSmith: I think Domenic made some reasonable arguments against that

[00:10:53.0000] <annevk>
MikeSmith: I think the problem would be gone too if we had an input and output directory

[00:11:02.0000] <MikeSmith>
ok

[00:12:31.0000] <MikeSmith>
annevk: remind where we discussed how we wanted that to work? was it on IRC, or is there an open issue that details the proposal/requirement?

[00:14:10.0000] <mkwst>
MikeSmith: https://github.com/whatwg/html-build/issues/3

[00:14:44.0000] <MikeSmith>
ah

[00:14:47.0000] <MikeSmith>
"Source repository history should not be intermingled with build tool revisions."

[00:14:56.0000] <MikeSmith>
I guess I actualy agree with that

[00:15:49.0000] <MikeSmith>
and I'm surprised/disappointed that I didn't think come to that conclusion on my own already

[00:15:54.0000] <MikeSmith>
I blame lack of sleep

[00:17:30.0000] <MikeSmith>
mkwst: anyway, thanks for the citation

[00:18:12.0000] <MikeSmith>
/me stares at the dozens of unread github notifications in his inbox

[00:18:41.0000] <mkwst>
As long as he's doing the work, I don't care. But it seems strange to pretend that these are really separate projects. *shrug* Whatever. I like green bikesheds! :)

[00:19:42.0000] <zcorpan>
MikeSmith: i checked the "Popular sites using UTF-16" and afaict they're not using utf-16

[00:20:51.0000] <zcorpan>
e.g. Epoker.com has Content-Type:·text/html;·charset=utf-8 and then <meta·http-equiv="Content-Type"·content="text/html;·charset=utf-16">

[00:21:15.0000] <zcorpan>
so i wouldn't give much weight to that statistic

[00:22:19.0000] <MikeSmith>
eh?

[00:22:25.0000] <zcorpan>
hmmm. sorry MikeSmith. i meant SimonSapin ^

[00:22:30.0000] <MikeSmith>
ah

[00:22:42.0000] <MikeSmith>
wake up, SimonSapin!

[00:22:48.0000] <zcorpan>
hsivonen: ^

[01:08:37.0000] <annevk>
mkwst: what is an endpoint origin?

[01:09:31.0000] <mkwst>
Given: `fetch("https://example.com/endpoint", { body: fd })`, it would be `example.com`.

[01:10:45.0000] <mkwst>
Basically, I'd like to be able to lock submissions down to a certain origin. The previous draft did so by overriding `fetch(url)` with `send(url)`, processing the URL there, and then setting a bunch of flags which prevented redirects.

[01:11:25.0000] <mkwst>
So, my thought at the moment is that I could put some flags on the FormData object which would govern the ways in which Fetch can use it.

[01:11:45.0000] <annevk>
https://code.google.com/p/chromium/codesearch#chromium/src/net/base/mime_util.cc&rcl=1427945811&l=384 a curious reference to w3schools

[01:12:09.0000] <mkwst>
annevk: Yeah. No idea. Let's git blame that, shall we? :)

[01:12:35.0000] <annevk>
also, there used to be a list of JavaScript MIME types there per https://www.w3.org/Bugs/Public/show_bug.cgi?id=28397 but they are now gone

[01:12:59.0000] <mkwst>
https://codereview.chromium.org/3311016 *shrug*

[01:15:14.0000] <annevk>
more like *shudder*

[01:16:08.0000] <mkwst>
https://blink.lc/chromium/tree/components/mime_util/mime_util.cc#n59

[01:16:47.0000] <mkwst>
which doesn't seem to match HTML, but also doesn't seem to have generated compatibility issues, since it hasn't changed in a long time,

[01:16:49.0000] <zcorpan>
Domenic: annevk: so what should i do differently to make PRs automatically close as merged?

[01:17:15.0000] <annevk>
zcorpan: I think the git push --force to the branch must have failed

[01:18:40.0000] <zcorpan>
$ git push --force

[01:18:40.0000] <zcorpan>
Everything up-to-date

[01:18:47.0000] <zcorpan>
it said

[01:23:48.0000] <annevk>
zcorpan: did you do git checkout branch-name too?

[01:24:01.0000] <zcorpan>
annevk: yes

[01:24:03.0000] <annevk>
and then git push --force and then git checkout master

[01:24:06.0000] <annevk>
hmm

[01:24:09.0000] <zcorpan>
yes

[01:24:44.0000] <annevk>
I haven't tried this new approach myself yet so I'm not a 100% that Domenic gave the correct instructions

[01:25:06.0000] <annevk>
but when you update the branch that should appear on the GitHub site

[01:26:12.0000] <zcorpan>
ok. yeah i didn't know what message to expect so i figured "Everything up-to-date" meant things were going a-OK

[01:36:23.0000] <annevk>
zcorpan: do you want to merge 69 or can I make an attempt?

[01:36:32.0000] <zcorpan>
annevk: do it

[01:38:27.0000] <annevk>
zcorpan: so yeah, I've had the same problem as you, I think Domenic's instructions are incomplete

[01:39:51.0000] <Ms2ger>
You probably want `git push --force origin <branch>`

[01:59:51.0000] <jgraham>
A more complete syntax is git push [options] <remote> <local_ref>:<remote_branch>

[02:00:21.0000] <jgraham>
the behaviour of bare git push depends on the defaults which depend on the version of git you are running

[02:00:39.0000] <jgraham>
(unless you changed them)

[02:19:45.0000] <annevk>
mkwst: e.g., you already forgot you can iterate FormData, see https://xhr.spec.whatwg.org/#formdata

[02:20:24.0000] <annevk>
mkwst: but you working through it SGTM

[02:20:44.0000] <mkwst>
annevk: s/forgot/didn't know/. But it's nice of you to assume competence.

[02:20:54.0000] <mkwst>
:)

[02:30:06.0000] <MikeSmith>
:-) >it's nice of you to assume competence

[02:32:37.0000] <MikeSmith>
one of the things that has always made me feel nice when hsivonen reviews code I write is that he always assumes I must have had a good rational reason for writing something in the way I did (instead of not actually having known the better way until he told me).

[02:50:13.0000] <beverloo>
MikeSmith, annevk: window.focus() works on Chrome as well. Thanks :)

[02:58:15.0000] <annevk>
MikeSmith: seems more folks are confused by the caniuse.com panel: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28709

[02:58:36.0000] <annevk>
MikeSmith: I wonder if we can adjust the stylesheet or closing mechanism somewhat to make it easier

[02:59:28.0000] <annevk>
MikeSmith: another thing that happens to me in Firefox is that once the scrollbar appears it goes right over the thing that allows you to close the widget, making it particularly hard to close

[03:05:29.0000] <annevk>
Okay, changing that requires changing Wattsi

[03:27:33.0000] <mkwst>
annevk: Should `toX` methods return a `Promise<X>` or `X`? It seems like some APIs do the one and some the other.

[03:28:17.0000] <annevk>
mkwst: depends on whether IO is involved I guess

[03:28:39.0000] <mkwst>
Hrm. Ok.

[03:28:52.0000] <mkwst>
I guess it's safer, but more cumbersome, to return a Promise.

[03:29:03.0000] <mkwst>
safer == future proof.

[03:29:41.0000] <annevk>
mkwst: if this is for FormData synchronous is fine

[03:29:48.0000] <mkwst>
it is.

[03:29:53.0000] <mkwst>
ok. that's simpler then.

[03:30:38.0000] <annevk>
I wonder if I can get the HTML bug count to be <300 by the end of the week

[03:30:56.0000] <mkwst>
That's easy. WONTFIX, WONTFIX, WONTFIX.

[03:33:41.0000] <darobin>
nah, with WONTFIX it is considered etiquette to at least explain why; which takes time

[03:33:50.0000] <darobin>
INVALID, INVALID, INVALID is much more efficient

[03:33:55.0000] <mkwst>
:)

[03:35:03.0000] <annevk>
That is how we got from ~500 to <400

[03:35:08.0000] <annevk>
It's a bit trickier now

[03:35:29.0000] <annevk>
As in, it involves work

[04:09:30.0000] <darobin>
MikeSmith: if you're around, can you please give me push access to w3c/gh-backup?

[04:10:13.0000] <MikeSmith>
yep

[04:10:34.0000] <MikeSmith>
gimme a minute, on from my mobile

[04:14:28.0000] <MikeSmith>
darobin: should be good to go now

[04:42:43.0000] <annevk>
mkwst: it seems like you can provide a PR for https://www.w3.org/Bugs/Public/show_bug.cgi?id=27852 right? It didn't break the web...

[04:43:02.0000] <mkwst>
I was looking at that yesterday. It's not clear to me where the sniffing is actually done in HTML.

[04:43:12.0000] <mkwst>
If you point me to the right spot, I'm happy to submit a PR.

[04:45:40.0000] <Ms2ger>
Somewhere around https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script ?

[04:46:36.0000] <annevk>
mkwst: <script> doesn't do any sniffing

[04:46:42.0000] <annevk>
mkwst: it just takes the response and executes it

[04:46:49.0000] <Ms2ger>
And things like importScripts?

[04:46:53.0000] <annevk>
mkwst: what you want is to prevent that

[04:47:14.0000] <annevk>
Ms2ger: it seems importScripts() also does some non-2xx check

[04:50:40.0000] <annevk>
mkwst: I guess it needs to be somewhere in https://html.spec.whatwg.org/multipage/scripting.html#execute-the-script-block but Ms2ger is correct that'd we also want to affect importScripts() and new Worker/new SharedWorker

[04:51:12.0000] <annevk>
So I guess a fix is not very straightforward

[04:51:52.0000] <Ms2ger>
I guess we'd need to start by factoring out "fetch a script source" or something

[04:51:56.0000] <annevk>
mkwst: doing it in Fetch might actually be easier, but I'm not sure if that's a good idea

[04:52:36.0000] <annevk>
Ms2ger: yeah, that kind of refactoring before doing the greater Fetch refactoring might be a good idea

[04:52:50.0000] <annevk>
I haven't really figured out how to best tackle Fetch refactoring yet

[04:52:57.0000] <annevk>
requires so many changes

[04:57:03.0000] <Ms2ger>
Yeah :/

[04:57:28.0000] <mkwst>
Well, I'm happy to give you a PR. I'm even happier to wait until you've done a lot of work to make my PR easy. :)

[04:57:51.0000] <mkwst>
doing it in Fetch seems simple. just return a network error given a set of properties on the request and the response mime type.

[04:57:58.0000] <mkwst>
but it's probably the wrong layer.

[04:58:14.0000] <Ms2ger>
I think so, yes

[05:09:10.0000] <hsivonen>
SimonSapin, zcorpan: I think zcorpan has previously shown w3techs.com to be bogus, but browser-based telemetry would be interesting

[05:09:45.0000] <SimonSapin>
hsivonen: so we don’t have telemetry for that yet?

[05:09:55.0000] <hsivonen>
annevk: what's the recommended way to test non-UTF encoders without relying on a server and using Web-exposed functionality only?

[05:10:04.0000] <hsivonen>
SimonSapin: AFAIK, we don't

[05:10:18.0000] <mkwst>
annevk: philipj asked me to expose the `opaque` flag to the web so we can test it in layout tests (and, I suppose, so folks could construct excitingly opaque FormData objects). Before I do that, how strongly do you feel about changing from `FormData` with a flag to `CredentialFormData`?

[05:13:24.0000] <philipj>
mkwst: well I didn't ask you to expose it, just if it should be exposed :)

[05:13:40.0000] <mkwst>
well, that seems to be an implicit request to expose it, right? :)

[05:13:41.0000] <philipj>
surely something should cause it to become set, which isn't currently the case

[05:13:44.0000] <darobin>
thanks MikeSmith!

[05:13:59.0000] <mkwst>
philipj: right. that's the second patch I sent you. :)

[05:14:07.0000] <philipj>
mkwst: eh, well OK :)

[05:14:27.0000] <philipj>
ah there it is, fd->makeOpaque()

[05:15:09.0000] <mkwst>
yeah. basically, i don't mind exposing that. i can't think of much of a use case, other than transferring a FormData object to a new context via `postMessage()`.

[05:15:25.0000] <mkwst>
but not being able to think of a use case is probably just my small-mindedness.

[05:15:31.0000] <mkwst>
maybe exposing every flag ever is good!

[05:15:59.0000] <mkwst>
(note, though, that it needs to be a one-way operation; JS shouldn't be able to unopaqueify an opaque object)

[05:22:53.0000] <hsivonen>
annevk: is there something smarter than http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3609 for accessing encoders purely on the client and using public APIs only?

[05:28:01.0000] <mkwst>
*sigh* why is testharness so wrong about the ordering of expected and actual values?

[05:28:24.0000] <philipj>
ask jgraham :)

[05:28:31.0000] <philipj>
what is the right order, agin?

[05:28:47.0000] <yoav>
I get those wrong *every* time

[05:28:49.0000] <mkwst>
the right order is expected, actual.

[05:28:55.0000] <mkwst>
testharness's order is backwards.

[05:29:06.0000] <mkwst>
:)

[05:29:36.0000] <Ms2ger>
What?

[05:29:56.0000] <Ms2ger>
actual, expected is the only sensibler order

[05:30:00.0000] <philipj>
mkwst: incidentally I was confused about why gtest has the "wrong" order not long ago, being very used to testharness

[05:31:21.0000] <mkwst>
philipj: Does https://codereview.chromium.org/1323043002 do what you wanted?

[05:31:44.0000] <philipj>
let me see if it induces happiness

[05:32:09.0000] <jgraham>
mkwst: FWIW I agree as you will see if you examine presto-testo for the testharnesses I wrote before testharness.js. It just turns out that the rest of the world largely disagrees.

[05:32:54.0000] <mkwst>
jgraham: Ok! So let's sneakily change it back and see if anyone notices!

[05:33:15.0000] <jgraham>
mkwst: I see you haven't worked with Ms2ger for long enough

[05:35:01.0000] <Ms2ger>
/me wanders up to mkwst 

[05:36:43.0000] <mkwst>
I haven't, actually, though I've gotten some good ms2ger feedback on various specs. :)

[05:37:15.0000] <Ms2ger>
Probably rather grumpy feedback :)

[05:37:23.0000] <annevk>
hsivonen: I don't think so, hadn't even thought of that approach, neat

[05:37:50.0000] <mkwst>
all feedback is good feedback. like, really. it's tough to get any feedback until something's shipping, and then it's somewhat late. :/

[05:38:05.0000] <annevk>
mkwst: how do you envision changing the FormData constructor?

[05:38:12.0000] <mkwst>
annevk: I don't.

[05:38:41.0000] <mkwst>
https://w3c.github.io/webappsec/specs/credentialmanagement/#dom-formdata-makeopaque is my current thought.

[05:39:48.0000] <annevk>
mkwst: isn't that extremely fragile from a security perspective?

[05:39:54.0000] <mkwst>
if you pick up https://github.com/whatwg/html/issues/62, that would change the `FormData(HTMLFormElement)` constructor.

[05:40:44.0000] <mkwst>
yes? i don't think `makeOpaque()` has any security value; it has explanatory value.

[05:41:11.0000] <mkwst>
currently, opaque FormData objects only make sense in the context of the credential management API, or write-only form fields.

[05:41:13.0000] <annevk>
Ms2ger: I recommend not replying to the <keygen> issue

[05:41:14.0000] <jgraham>
" see if anyone notices" where Ms2ger ∈ anyone is always true

[05:41:39.0000] <Ms2ger>
annevk, but someone is wrong on the internet!

[05:41:47.0000] <mkwst>
there's no other case I know of in which they offer any value, as all the data's already available to JavaScript.

[05:41:59.0000] <Ms2ger>
(point taken)

[05:42:31.0000] <annevk>
mkwst: I think if we expose anything it should be part of the constructor

[05:42:53.0000] <mkwst>
annevk: how does that help?

[05:43:34.0000] <annevk>
mkwst: seems more robust

[05:43:35.0000] <mkwst>
that is, how is `FormData(form, { opaque: true })` better than `var fd = FormData(form); fd.makeOpaque();`? I suppose it's prettier?

[05:43:42.0000] <mkwst>
robust against what? :)

[05:44:00.0000] <annevk>
mkwst: e.g., you can use a different data structure for the internals then

[05:44:45.0000] <annevk>
mkwst: anyway, I don't think we should expose the slot for v1

[05:44:50.0000] <annevk>
mkwst: seems like feature creep

[05:45:03.0000] <mkwst>
what do you mean?

[05:45:23.0000] <annevk>
mkwst: it adds complexity in the design process while not solving any problems

[05:45:56.0000] <mkwst>
I'm not following. We need to somehow expose the password to something, otherwise the user can't sign in with it.

[05:47:24.0000] <annevk>
What does the password have to do with exposing opaque to JavaScript?

[05:48:32.0000] <mkwst>
Oh, I see. You're calling the flag a slot. Got it.

[05:49:08.0000] <mkwst>
I don't think we need to expose opaque to JavaScript, but doing so make it possible to write DOM-based layout tests instead of just unit tests for the C++ code.

[05:49:21.0000] <mkwst>
Also: this was philipj's idea. :)

[05:49:40.0000] <mkwst>
See https://codereview.chromium.org/1323043002/#ps20001.

[06:02:22.0000] <philipj>
It's fine with me if it isn't web-exposed, should still be possible to test opaque-ness by using toFormData I think

[06:03:39.0000] <mkwst>
philipj: Yeah. It's a bit roundabout, but since that's the only thing that creates an opaque FormData object, it's a totally reasonable way of testing the feature. I'll drop it. Adding it back is trivial if annevk changes his mind. :)

[06:04:21.0000] <philipj>
annevk never changes his mind, he was born with all the right opinions

[06:04:35.0000] <mkwst>
lucky guy.

[06:04:56.0000] <MikeSmith>
agree it's a bad idea to feed that keygen troll

[06:15:42.0000] <mkwst>
So. Anyone have a thesaurus handy? I need a word that means "credential" but that isn't "credential". :)

[06:18:15.0000] <jgraham>
http://www.thesaurus.com/browse/credential

[07:05:26.0000] <johnme>
annevk: for notification actions (https://github.com/whatwg/notifications/pull/48), I've realised the event delivered to pages shouldn't inherit from ExtendableEvent.

[07:05:28.0000] <johnme>
annevk: Should I rename NotificationEvent to PersistentNotificationEvent, and introduce a new NonPersistentNotificationEvent?

[07:06:34.0000] <annevk>
johnme: interesting, does this feature even make sense for toast-like notifications?

[07:06:51.0000] <johnme>
might depend on the platform

[07:07:28.0000] <annevk>
johnme: provided you want to keep it, I suggest not renaming NotificationEvent, but only introducing NonPersistentNotificationEvent, or perhaps ToastNotificationEvent...

[07:08:21.0000] <johnme>
ok

[07:09:00.0000] <johnme>
(I checked github and could find almost zero mentions of NotificationEvent)

[07:13:57.0000] <annevk>
mkwst: johnme: do you know who does autocomplete in Chrome? https://www.w3.org/Bugs/Public/show_bug.cgi?id=28952 has a suggestion

[07:15:39.0000] <mkwst>
Wow. I thought Heidegger died. And I didn't know he built websites.

[07:16:16.0000] <mkwst>
Oh no.

[07:16:38.0000] <mkwst>
TBL on www-tag@. :(

[07:17:25.0000] <mkwst>
https://lists.w3.org/Archives/Public/www-tag/2015Sep/0000.html

[07:20:40.0000] <annevk>
Maybe someone should tell timbl that you need HTTPS for <keygen>

[07:20:44.0000] <annevk>
/me hides

[07:24:55.0000] <johnme>
annevk: mathp & thestig (both @chromium.org) are probably good people to talk to about autofill

[07:28:54.0000] <johnme>
annevk: after chatting to peter, I think I'll drop actions from non-persistent notifications for now (due to the uncertainty around moving to toast notifications)

[07:36:17.0000] <Workshiva>
I wonder if there are numbers on frequency of http vs https in keygen usage

[07:48:48.0000] <annevk>
johnme: thank you, pinged them

[08:23:27.0000] <wanderview>
JakeA: annevk: I don't support either of you have an opinion on this issue before we change our tests to do one or the other? https://github.com/slightlyoff/ServiceWorker/issues/742

[08:27:59.0000] <annevk>
wanderview: so is scriptURL the final after redirects URL?

[08:28:30.0000] <wanderview>
/me looks

[08:29:20.0000] <wanderview>
annevk: it appears the scriptURL is set before fetching the script... so I would say before any redirects

[08:31:16.0000] <wanderview>
annevk: as far as I can tell the script URL is never updated based on the final redirected URL

[08:33:38.0000] <annevk>
wanderview: hmm

[08:33:47.0000] <annevk>
wanderview: so for Request it returns the URL without the fragment

[08:33:59.0000] <wanderview>
yes

[08:34:00.0000] <annevk>
wanderview: but there's also a dozen other APIs that will return it with

[08:34:07.0000] <annevk>
wanderview: so maybe Request is wrong

[08:34:10.0000] <wanderview>
I don't think this uses Request in the register() path

[08:34:24.0000] <wanderview>
annevk: you're making me sad right now

[08:34:34.0000] <wanderview>
we just fixed Request to strip the fragment :-\

[08:34:35.0000] <annevk>
wanderview: that doesn't really matter when looking for consistency though

[08:35:21.0000] <annevk>
Yeah I don't know, the fragment is useless...

[08:36:36.0000] <wanderview>
annevk: I can't see a reason to keep the fragment... and it appears chrome strips it for the script URL

[09:27:57.0000] <ccardona-work>
Good morning/afternoon/evening WHATWG crew 😎

[09:32:03.0000] <annevk>
Domenic: https://github.com/whatwg/dom/issues/61#issuecomment-136773368

[09:32:21.0000] <annevk>
The base URL story changes yet again

[09:32:28.0000] <Domenic>
Yeah...

[09:33:07.0000] <Domenic>
annevk: couldn't in theory it still be lazy though? e.g. if selector matching just looked at .href?

[09:33:18.0000] <Domenic>
annevk: oh no i get it

[09:34:30.0000] <Domenic>
Sebmaster ^

[09:38:40.0000] <Sebmaster>
oh :(

[09:38:46.0000] <Sebmaster>
well, could still do parsing lazily i guess

[09:39:48.0000] <Sebmaster>
i guess it depend how the pseudo-class is implemented, but I think it could be done lazily anyways

[09:41:48.0000] <Domenic>
I thought about that

[09:42:18.0000] <Domenic>
It would be very convoluted. You'd want to re-compute the pseudo class matching every frame for drawing.

[09:42:29.0000] <Domenic>
So, not really an option.

[09:42:45.0000] <Domenic>
(Plus you'd need to make sure it gets recomputed whenever someone does selector matching.)

[09:42:53.0000] <annevk>
Domenic: I found https://github.com/whatwg/html/commit/78f1994463a1f19685ea2ca5beb335ca2a91ca14

[09:42:57.0000] <Domenic>
href can still be lazy

[09:43:11.0000] <annevk>
Domenic: what is the correct GitHub syntax to link that?

[09:43:21.0000] <Domenic>
annevk: 78f1994463a1f19685ea2ca5beb335ca2a91ca14

[10:13:08.0000] <Yuhong>
Something where we actually care about W3C's patent policy: https://blog.mozilla.org/blog/2015/09/01/forging-an-alliance-for-royalty-free-video/

[10:16:12.0000] <Yuhong>
It is not actually developed within W3C though.

[10:17:45.0000] <Domenic>
As far as I can tell the winning codec is the one that gets all the chipset manufacturers to build hardware decoders

[10:19:47.0000] <annevk>
Domenic: I can't figure out how to change the commit message

[10:20:04.0000] <Domenic>
annevk: git commit --amend -m "new message" should do the trick

[10:20:28.0000] <annevk>
Domenic: that will not change the title?

[10:20:48.0000] <Domenic>
annevk: title is a human concept...

[10:21:00.0000] <Domenic>
oh you mean of the PR itself?

[10:21:05.0000] <Domenic>
That doesn't end up mattering

[10:21:12.0000] <annevk>
Domenic: no I meant of the commit

[10:21:21.0000] <Domenic>
Yeah title just means first line of message

[10:21:22.0000] <annevk>
Domenic: how I handle newlines? Does \n work?

[10:21:36.0000] <Domenic>
Good question...

[10:21:50.0000] <Domenic>
oh

[10:21:55.0000] <Domenic>
just git commit --amend and then you'll get a text editor

[10:22:29.0000] <annevk>
Domenic: yeah not one I can use though... I guess I can try

[10:22:50.0000] <Domenic>
git config --global core.editor subl

[10:23:16.0000] <Domenic>
(I think subl = sublime text on macs...)

[10:23:32.0000] <annevk>
Ah, is that the command-line way to launch your editor?

[10:23:40.0000] <annevk>
Mine responds to "edit resource"

[10:23:59.0000] <annevk>
So would I use git config --global core.editor edit?

[10:24:19.0000] <annevk>
yes

[10:24:22.0000] <annevk>
cool

[10:26:02.0000] <annevk>
Hmm that didn't work

[10:28:13.0000] <annevk>
Domenic: so it opens the editor with .git/COMMIT_EDITMSG which I modify and save and then I run git push --force but nothing

[10:32:30.0000] <Domenic>
-_-

[10:33:15.0000] <Domenic>
http://stackoverflow.com/a/15008335/3191

[10:33:40.0000] <Domenic>
Looks like this --wait option is important

[10:33:48.0000] <Domenic>
Want to give it a try? Otherwise I can do it.

[10:34:05.0000] <annevk>
Okay

[10:34:51.0000] <jamesr___>
git relies on the exit code from whatever editor it spawns

[10:37:21.0000] <Domenic>
\o/

[10:37:27.0000] <annevk>
/me finds http://stackoverflow.com/questions/13257519/how-to-change-the-default-editor-for-git

[10:37:58.0000] <annevk>
Which seems to have worked, yay

[10:38:56.0000] <Domenic>
so currently your selectors-attribute-value is not on top of master

[10:40:45.0000] <annevk>
Okay, so that is what went wrong?

[10:41:37.0000] <annevk>
I guess I needed to amend and do git rebase then?

[10:42:11.0000] <Domenic>
yeah rebase is the trick

[10:42:22.0000] <Domenic>
rebase then push

[10:42:25.0000] <Domenic>
(force push)

[10:42:46.0000] <annevk>
Do you do the rebase before running pr?

[10:43:13.0000] <Domenic>
So the problem with pr is that it works in this other temporary branch, named pr/74

[10:43:17.0000] <annevk>
We need to write down the explicit steps under merge policy I think

[10:43:47.0000] <Domenic>
that is mainly because when other people without access to the repo do PRs, there is no corresponding whatwg/selectors-attribute-values branch

[10:45:16.0000] <Domenic>
In your case what you could have done (but again this is all kind of silly) is manually done these three steps from pr(): https://gist.github.com/domenic/11371574#file-bashrc-L4-L6

[10:45:38.0000] <Domenic>
just instead of `pr/$1` you'd do it with your local `selectors-attribute-values`

[10:46:14.0000] <Domenic>
i can make this easier with more scripts, let me see.

[10:46:26.0000] <annevk>
Would you mind adding both set of steps to the README?

[10:46:34.0000] <annevk>
For external branches and local branches?

[10:47:09.0000] <gsnedders>
Yet another person missing the "element refer to element in the HTML namespace" in the terminology section. I wonder if it's worthwhile revisiting that, given it causes so many bugs.

[10:49:03.0000] <Domenic>
yeah

[10:49:17.0000] <Domenic>
(to adding steps)

[10:51:31.0000] <annevk>
gsnedders: if you have suggestions or a PR :-)

[10:53:09.0000] <gsnedders>
annevk: well the only real option is to explicitly state "HTML element" everywhere, which seems pretty bad. It simultaneously reduces readibility and improves it (verbosing v. redefining common terms)

[10:53:51.0000] <annevk>
gsnedders: html:select

[10:54:04.0000] <annevk>
but no, let's not do that

[10:55:05.0000] <annevk>
gsnedders: perhaps we could have "select element" and have "element" here link to "HTML element"

[11:03:47.0000] <gsnedders>
annevk: it's caused enough bugs in enough things, though. like, the confusion from redefining the term is real, and is a problem. :|

[11:29:44.0000] <Sebmaster>
linking in the url spec was pretty sweet to differentiate between local vs state variables. I thought that was pretty nice

[13:12:58.0000] <aklein>
Domenic: more Map/Set fixes in cloining in https://github.com/whatwg/html/pull/82

[13:19:54.0000] <Domenic>
aklein: great, will review by tomorrow at the latest; really gotta work on some other stuff today :P

[13:51:31.0000] <aklein>
Domenic: np, just feel bad that I didn't fix it properly the first time

[13:53:25.0000] <Stevef_>
annevk: hi, is it worth me opening issues for author conformance and advice differences between whatwg/w3c html?

[13:55:16.0000] <Stevef_>
annevk: for example, I filed this one https://github.com/whatwg/html/issues/83


2015-09-02
[22:24:23.0000] <annevk>
Woohoo, clean merge

[22:28:00.0000] <MikeSmith>
annevk: big patch?

[22:28:07.0000] <MikeSmith>
/me checks the commit log

[22:28:42.0000] <annevk>
MikeSmith: nah it was simple, but it's properly linked to the PR and the PR appears purple

[22:28:58.0000] <MikeSmith>
hmm did you push it already?

[22:29:11.0000] <MikeSmith>
commit log has "annevk authored 13 hours ago"

[22:29:21.0000] <annevk>
MikeSmith: I just pushed it though

[22:29:26.0000] <MikeSmith>
ah yeah OK

[22:29:59.0000] <MikeSmith>
yeah that shows when you committed it, that timestamp

[22:30:22.0000] <annevk>
13h ago it was not Sep 2 here :-)

[22:32:22.0000] <MikeSmith>
nice work on all those patches

[22:32:38.0000] <MikeSmith>
and nice work on whittling away at the W3C bugs

[22:32:54.0000] <MikeSmith>
https://www.w3.org/Bugs/Public/buglist.cgi?component=HTML&list_id=59308&product=WHATWG&resolution=--- now at 334 bugs

[22:34:05.0000] <MikeSmith>
though the curve on the open is now way bent toward "this is not going to be easy or quick to resolve" bugs

[22:34:16.0000] <MikeSmith>
*on the open bugs is now

[22:36:02.0000] <annevk>
Yeah, so I'd like to actually make a collection of somewhat easy-to-fix bugs if there are any left. Through Mozilla I can get funding for an Outreachy intern (and meanwhile we try to figure out how to get diversity grants done right) and I thought a good project might be submitting patches to the HTML Standard

[22:36:03.0000] <MikeSmith>
annevk: I notice that https://www.w3.org/Bugs/Public/show_bug.cgi?id=28821 already has a PR (though against the W3C fork)

[22:36:13.0000] <MikeSmith>
annevk: oh

[22:36:27.0000] <MikeSmith>
cool to hear that you got funding for somebody to help

[22:37:48.0000] <MikeSmith>
as far as https://www.w3.org/Bugs/Public/show_bug.cgi?id=28821 maybe we could ask that commenter (Scott Beardsley) to re-submit that patch against the https://github.com/whatwg/html sources

[22:38:02.0000] <MikeSmith>
OK if I comment on that bug to say as much?

[22:38:16.0000] <annevk>
MikeSmith: oh sorry, I just did

[22:38:24.0000] <MikeSmith>
ah ok

[22:38:27.0000] <MikeSmith>
no worries

[22:39:01.0000] <annevk>
MikeSmith: since I guess it has to be said, feel free to comment on any bug as you wish, and continue to feel free to resolve them too

[22:39:07.0000] <annevk>
:-)

[22:39:10.0000] <MikeSmith>
ah okk

[22:45:46.0000] <MikeSmith>
I wonder what problem for Web users and Web developers in practice the Alliance for Open Media thing is actually going to solve without Apple on board

[22:46:00.0000] <MikeSmith>
roc: ↑

[22:46:45.0000] <MikeSmith>
after reading http://aomedia.org/press-release/alliance-to-deliver-next-generation-open-media-formats/

[22:46:51.0000] <MikeSmith>
and https://blog.mozilla.org/blog/2015/09/01/forging-an-alliance-for-royalty-free-video/

[22:47:15.0000] <roc>
well, it's not clear Apple won't get on board.

[22:47:37.0000] <MikeSmith>
ah ok

[22:47:49.0000] <roc>
I mean, I don't know anything

[22:48:44.0000] <MikeSmith>
I guess I would assume that they would have delayed the announcement if they thought Apple was going to be getting on board in the near term

[22:48:59.0000] <MikeSmith>
but yeah it's not productive to speculate

[22:49:04.0000] <roc>
the timing of the announcement was driven by external factors not related to Apple

[22:49:56.0000] <MikeSmith>
ah OK

[22:50:19.0000] <MikeSmith>
well it's clearly a really good thing

[22:50:22.0000] <roc>
If the AOM achieves its goals of bringing an unencumbered video codec to market, and Netflix, Amazon and Google follow through by supporting it in their respective video services, then that would be pretty great for software freedom

[22:50:34.0000] <MikeSmith>
absolutely

[22:50:39.0000] <roc>
and leave Apple and other client holdouts in a difficult position

[22:50:46.0000] <MikeSmith>
yup

[22:51:00.0000] <roc>
we can assume Netflix, Amazon and Google would not also support HEVC (or what's the point of AOM?)

[22:51:01.0000] <MikeSmith>
having Amazon on board with it is pretty big

[22:51:07.0000] <MikeSmith>
yeah

[22:51:40.0000] <roc>
so you'd have a situation where watching video on an iPhone takes twice the bandwidth of using any other device

[22:52:01.0000] <roc>
unless you bought it through iTunes I guess

[22:52:14.0000] <MikeSmith>
hmm

[22:52:28.0000] <roc>
how long would Apple tolerate that?

[22:52:29.0000] <MikeSmith>
yeah that's a pretty big "unless", given the state of things

[22:52:36.0000] <MikeSmith>
I dunno

[22:53:09.0000] <roc>
so I don't think Apple holding out is really relevant at all.

[22:53:25.0000] <MikeSmith>
how long to Apple users tolerate the fact that they don't have the freedom to install whatever browser/browser-engine they want on their iPhone?

[22:54:01.0000] <MikeSmith>
*how long have/will Apple users tolerated

[22:54:03.0000] <roc>
Apple's position is that you use apps instead, which kind of works

[22:54:27.0000] <MikeSmith>
for some definition of "kind of"

[22:54:47.0000] <roc>
but there's no getting around higher data charges for Netflix and Youtube

[22:54:53.0000] <MikeSmith>
yeah sure

[22:55:30.0000] <roc>
if you're looking for pessimistic spin on AOM, it's that maybe Netflix, Amazon, and Microsoft are just looking for bargaining leverage against the HEVC licensors

[22:55:31.0000] <MikeSmith>
but I can imaging Apple working with Netflix to get something special arranged

[22:55:38.0000] <MikeSmith>
oh

[22:55:50.0000] <roc>
Apple can't really do anything to fix the HEVC licensing situation for Netflix

[22:55:51.0000] <MikeSmith>
well I wasn't looking for a pessimistic spin on it :)

[22:55:57.0000] <MikeSmith>
ok

[22:57:06.0000] <annevk>
roc: doesn't Netflix do H265 for 4K? Or can you do that using H264 too?

[22:58:09.0000] <roc>
you sure can

[22:58:16.0000] <roc>
it's more bandwidth

[22:59:01.0000] <roc>
Netflix was in the H.265 camp, which is why this AOM announcement is big news.

[23:02:15.0000] <roc>
I assume the H.265 licensing disaster has spooked them.

[23:05:52.0000] <annevk>
Well, hopefully it works out

[23:06:31.0000] <roc>
I hope it works out with us winning

[23:06:54.0000] <annevk>
Me too, but I'm still somewhat scarred by the WebM experiment

[23:07:15.0000] <roc>
what about it?

[23:10:12.0000] <annevk>
roc: well I was all excited back then too about open media having a chance yet here we are with H264 mandated in practice

[23:10:37.0000] <roc>
 yes

[23:10:44.0000] <roc>
things have changed

[23:11:14.0000] <roc>
one big advantage we have this time around is that there is a pretty-good video codec with hardware support everywhere: H.264

[23:11:18.0000] <terinjokes>
is there any information on how AOM intends to do this? leveraging Thor?

[23:11:55.0000] <annevk>
terinjokes: from the post "We believe that Daala, Cisco’s Thor, and Google’s VP10 combine to form an excellent basis for a truly world-class royalty-free codec."

[23:11:56.0000] <roc>
I imagine the plan is to come up with something that's a combination of Daala, Thor and VPx

[23:12:15.0000] <roc>
it depends on who's serious

[23:12:36.0000] <terinjokes>
annevk: reading comprehension failed. sorry

[23:12:43.0000] <roc>
Microsoft has some good codec expertise, but it's unclear how enthusiastic they really are

[23:13:38.0000] <roc>
annevk: the other thing is the H.265 licensing mess. If H.265 licensing was just like H.264s AOM wouldn't be happening.

[23:13:40.0000] <annevk>
From Twitter it seems they're plenty enthusiastic, but that doesn't tell you much

[23:14:04.0000] <annevk>
roc: are you afraid the H265 camp will make a counteroffer?

[23:14:48.0000] <roc>
it's possible that some AOM members are in with that as their goal

[23:15:00.0000] <roc>
the good news for us is that there isn't an "H.265 camp"

[23:15:06.0000] <roc>
there are at least two warring camps

[23:15:25.0000] <roc>
maybe more considering I've heard 1/3 of H.265 patent holders haven't committed to MPEG-LA or HEVC Advance yet.

[23:16:05.0000] <MikeSmith>
wow

[23:16:18.0000] <roc>
if HEVC Advance lower their pricing structure to similar to MPEG-LA's, then HEVC loses its reason to exist

[23:16:26.0000] <roc>
and organizations like to exist

[23:17:20.0000] <roc>
it gets even more amusing considering all the HEVC hardware that's shipping, e.g. iPhone 6

[23:17:55.0000] <roc>
that momentum was great for HEVC ... except that now those vendors have no idea how much royalties they'll have to pay *for hardware they've already shipped*

[23:22:28.0000] <MikeSmith>
one would hope that realization that anybody actually rational would have at this point is: Patent pools are horrible.

[23:22:43.0000] <MikeSmith>
*non-RF patent pools

[23:35:15.0000] <MikeSmith>
annevk: is it valid to do Access-Control-Allow-Headers: *

[23:35:22.0000] <annevk>
MikeSmith: no

[23:35:25.0000] <MikeSmith>
with the wildcard I mean?

[23:35:28.0000] <MikeSmith>
yeah, OK

[23:35:30.0000] <MikeSmith>
thought so

[23:35:39.0000] <MikeSmith>
thanks

[23:36:24.0000] <MikeSmith>
roc: dunno about your music tastes but your countryman Marlon Williams is great http://www.marlonwilliams.co.nz/ (/me is listening to "Dark Child") and I would go see his live show if lived nearby

[23:36:47.0000] <annevk>
Now I wonder what iPhone 6s will ship with

[23:37:40.0000] <MikeSmith>
Auckland Oct 15  http://www.marlonwilliams.co.nz/show/holy-trinity-auckland-the-church-tour-with-delaney-davidson-tami-neilson-barry-saunders/

[23:37:57.0000] <MikeSmith>
annevk: video support you mean?

[23:38:10.0000] <annevk>
MikeSmith: yeah, if they will continue to ship hardware that will make them pay

[23:38:14.0000] <MikeSmith>
ah

[23:38:45.0000] <annevk>
That would be an interesting indicator of where Apple stands, though perhaps iPhone 6s is too baked/soon to speculate

[23:40:21.0000] <MikeSmith>
yeah I would think too baked but who knows

[23:40:43.0000] <MikeSmith>
anyway, speculating his hard! let's land patches!

[23:42:06.0000] <MikeSmith>
annevk: so just looking at things from a webdev PoV, where does a webdev go learn that Access-Control-Allow-Headers can't be wilcard?

[23:42:34.0000] <annevk>
MikeSmith: https://fetch.spec.whatwg.org/#http-new-header-syntax is pretty clear

[23:42:43.0000] <MikeSmith>
annevk: https://fetch.spec.whatwg.org/#http-new-header-syntax

[23:43:04.0000] <MikeSmith>
annevk: yeah I don't think it's clear enough to the average webdev

[23:43:06.0000] <annevk>
MikeSmith: hmm, although token does include *

[23:43:07.0000] <MikeSmith>
oh

[23:43:12.0000] <MikeSmith>
hmm

[23:43:25.0000] <annevk>
So I guess it's allowed, but * matches a header name?

[23:43:34.0000] <annevk>
Rather than act as a wildcard...

[23:43:39.0000] <MikeSmith>
oh

[23:43:43.0000] <MikeSmith>
that makes sense

[23:43:50.0000] <MikeSmith>
but it's not intuitive

[23:43:58.0000] <annevk>
https://fetch.spec.whatwg.org/#http-access-control-allow-headers is also pretty clear that it only allows headers to be listed

[23:44:10.0000] <MikeSmith>
/me looks

[23:44:43.0000] <MikeSmith>
well, with all due respect, I don't consider that to be pretty clear

[23:45:14.0000] <MikeSmith>
but maybe I'm trying to think too lowest-common-denominator

[23:45:35.0000] <MikeSmith>
as far was what's clear to the average dev

[23:45:45.0000] <MikeSmith>
but anyway I wasn't really criticizing the spec on this

[23:45:55.0000] <MikeSmith>
it should be clear in other places, like MDN

[23:46:07.0000] <annevk>
MikeSmith: I'm happy to take PRs

[23:46:10.0000] <MikeSmith>
and yeah I know I can update the MDN pages myself to make it more clear

[23:46:14.0000] <MikeSmith>
annevk: k

[23:46:22.0000] <MikeSmith>
/me is just kvetching at this point

[23:46:26.0000] <annevk>
heh

[23:46:46.0000] <annevk>
I'm happy to make improvements

[23:47:41.0000] <MikeSmith>
annevk: I think you know already that IMHO the spec isn't the best place to try to make things clear for authors

[23:48:00.0000] <MikeSmith>
especially if what's added is distracting/noisy to implementors

[23:48:16.0000] <MikeSmith>
*specs in general are the best place

[23:48:29.0000] <annevk>
Have to strike some balance; e.g., I'd like you to be able to understand

[23:48:33.0000] <MikeSmith>
sure

[23:48:38.0000] <MikeSmith>
fair enough

[23:48:49.0000] <MikeSmith>
but in my case I'm just lazy

[23:49:05.0000] <MikeSmith>
that said, I guess many others are equally lazy

[23:49:18.0000] <MikeSmith>
but we shouldn't optimize for laziness

[23:52:40.0000] <MikeSmith>
annevk: it is accurate to say that Access-Control-Allow-Origin is the *only* header that allows a wildcard?

[23:52:49.0000] <MikeSmith>
*is it accurate

[23:53:17.0000] <MikeSmith>
*sometimes allows a wildcard

[23:53:33.0000] <annevk>
of the Access-Control-* headers, yes

[23:53:39.0000] <MikeSmith>
k

[23:53:41.0000] <MikeSmith>
thanks

[23:54:03.0000] <terinjokes>
also worth noting that there's no list syntax for Access-Control-Allow-Origin, as a coworker found out the end of the last week

[00:48:05.0000] <hsivonen>
/me finds a bug in the big5 encoder algorithm

[00:58:27.0000] <hsivonen>
filed as https://github.com/whatwg/encoding/issues/9

[01:00:15.0000] <annevk>
terinjokes: folks keep getting confused by that

[01:00:39.0000] <annevk>
terinjokes: the original specification allowed space-separated origins, but they were for redirects, not anything like allowing multiple origins...

[01:02:23.0000] <annevk>
hsivonen: could you take a look at https://github.com/whatwg/html/pull/66?

[01:05:42.0000] <hsivonen>
annevk: reviewing now

[01:19:45.0000] <zcorpan>
ok one step towards fixing web-apps-tracker https://gist.github.com/zcorpan/5f0e36efdd35b800a6be

[01:20:23.0000] <annevk>
I'm using [good first bug] in the whiteboard to annotate bugs for potential interns

[01:20:31.0000] <annevk>
Please don't fix them :-)

[01:20:50.0000] <annevk>
zcorpan: so...

[01:21:00.0000] <annevk>
zcorpan: you know web-apps-tracker uses the git repository right?

[01:21:08.0000] <annevk>
zcorpan: it should be easier than that

[01:21:32.0000] <annevk>
zcorpan: it finds the git commit by searching for the SVN ID embedded in it

[01:21:41.0000] <annevk>
s/ID/revision/

[01:22:04.0000] <annevk>
zcorpan: though I guess we could use this for a .htaccess file

[01:22:22.0000] <annevk>
zcorpan: which seems nice due to its staticness

[01:22:27.0000] <zcorpan>
annevk: yeah. seems pointless to parse the gitlog every time when it's a fixed list

[01:22:36.0000] <annevk>
carry on :-)

[01:23:28.0000] <mkwst>
annevk: What is Body::json supposed to return for a Request object?

[01:23:29.0000] <zcorpan>
do we want to redirect the old urls with query strings?

[01:23:38.0000] <annevk>
mkwst: {} I suspect

[01:24:01.0000] <annevk>
mkwst: oh wait, you're not talking about the JSON serializer thingie

[01:24:11.0000] <mkwst>
I'm talking about the body mixin.

[01:24:24.0000] <annevk>
mkwst: request.json() returns the body of the request as a JSON object

[01:24:46.0000] <mkwst>
Ok, so if the body doesn't parse as JSON, it just explodes.

[01:24:48.0000] <annevk>
zcorpan: yes

[01:25:13.0000] <annevk>
mkwst: SyntaxError, iirc

[01:25:29.0000] <mkwst>
annevk: right. SyntaxExplosion. :)

[01:25:49.0000] <annevk>
mkwst: maybe in Chrome :-P

[01:25:51.0000] <mkwst>
annevk: Does Firefox implement the `formData` method? Chrome apparently doesn't.

[01:26:01.0000] <annevk>
mkwst: it might not

[01:26:47.0000] <mkwst>
ok. interesting.

[01:28:07.0000] <mkwst>
are these methods intended to allow casting? like, if I do `new Request(..., { body: formDataObject });`, I can get the encoded data back via `text()`. Should I be able to get the original FormData back via `formData()`? Should I get a blob via `blob()`?

[01:28:35.0000] <mkwst>
Or are they meant to only work when their type was passed in as RequestInit::body?

[01:29:29.0000] <mkwst>
(Sorry, these are stupid questions.)

[01:30:15.0000] <annevk>
mkwst: "casting" should work

[01:31:03.0000] <annevk>
mkwst: no worries; if you couldn't tell from reading the specification, perhaps we should add some examples...

[01:31:12.0000] <annevk>
mkwst: speaking of which, if you want to make more PRs...

[01:31:52.0000] <mkwst>
annevk: hey! let me finish my specs before making me work on yours. :) I'm busy "improving" fetch and XHR via the magic of monkey patches.

[01:36:20.0000] <hsivonen>
annevk: review done

[01:36:29.0000] <annevk>
hsivonen: thank you, those comments look great

[01:54:56.0000] <mkwst>
annevk: (Sorry, more opaque FormData questions.) Would you be sad if it wasn't possible to construct a `Request` object from JavaScript using a RequestInit object whose `body` was an opaque FormData? That is, `fetch(..., { body: oFD, ... })` would work, but `new Request(..., { body: oFD, ... })` wouldn't?

[01:55:26.0000] <mkwst>
annevk: it doesn't look like the former would expose the Request object to JavaScript, which means we wouldn't have to monkey patch Request to deny external access to the data while allowing internal access.

[01:56:06.0000] <annevk>
mkwst: the former uses new Request() literally so I'm not sure how you'd monkey patch your way out of that...

[01:57:32.0000] <mkwst>
Request(): 1. If opaque, reject. 2. Call InternalRequest(). InternalRequest(): [copy/paste the existing Request()]. :)

[01:58:18.0000] <mkwst>
basically split the construction algorithm out into "construct a Request object", and have the IDL constructor do the opacity check.

[01:59:40.0000] <annevk>
mkwst: so how would this work with the Cache API?

[01:59:59.0000] <annevk>
mkwst: if you do cache.add(url, {body:oFD}) and then enumerate the requests?

[02:00:00.0000] <mkwst>
Cache works on Responses, doesn't it?

[02:00:08.0000] <annevk>
mkwst: it stores both

[02:01:30.0000] <mkwst>
Where is this defined? Service Worker?

[02:03:02.0000] <mkwst>
if Cache is only available in Service Worker, then I don't think we need to care since the credential isn't available in the SW context.

[02:03:15.0000] <annevk>
Cache is everywhere

[02:03:23.0000] <mkwst>
but I take your point. Request data is exposed all over the place. Ugh.

[02:04:02.0000] <annevk>
Hmm yeah, speaking of which, we'll have a fetch observation API at some point, that'll also expose the Request object

[02:04:31.0000] <mkwst>
...

[02:05:12.0000] <annevk>
mkwst: https://github.com/whatwg/fetch/issues/65

[02:05:48.0000] <mkwst>
Can I call for a moratorium on new Request exposure? :)

[02:06:06.0000] <annevk>
That's easy, denied!

[02:06:55.0000] <mkwst>
you're mean.

[02:08:15.0000] <mkwst>
skimming Fetch, it's not clear whether Request exposes 'forbidden' header values. does it?

[02:09:36.0000] <mkwst>
it stops sets and deletes, but not gets, apparently.

[02:10:30.0000] <annevk>
mkwst: they won't be in there

[02:10:53.0000] <annevk>
mkwst: forbidden headers are set post service workers

[02:11:03.0000] <annevk>
just before the network

[02:50:30.0000] <smaug____>
annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25897 is a 'good first bug' ?

[02:50:50.0000] <smaug____>
from implementation point of view that is very tricky one

[02:50:59.0000] <smaug____>
what if focusin/out do something unexpected...

[02:51:19.0000] <annevk>
smaug____: I wasn't sure  about that one, the comments suggested it was just going to be firing some more events

[02:51:40.0000] <annevk>
smaug____: could you maybe add a comment and clear the whiteboard?

[02:51:55.0000] <smaug____>
k

[02:52:03.0000] <annevk>
thank you

[02:59:12.0000] <MikeSmith>
bravo StackOverflow. One of the Free Pascal devs actually posted an answer to the SO question I posted about the compiling/linking problem I ran into when trying to compile the wattsi code to do the HTML spec build

[02:59:37.0000] <MikeSmith>
http://stackoverflow.com/a/32349608/441757

[02:59:56.0000] <MikeSmith>
"strictly the original source is buggy"

[03:00:18.0000] <MikeSmith>
I won't tell Hixie that he said that

[03:01:20.0000] <MikeSmith>
they still have a bug to fix in their compiler on OSX though

[03:03:56.0000] <MikeSmith>
oh they already responded to that

[03:04:02.0000] <MikeSmith>
http://bugs.freepascal.org/view.php?id=28588

[03:04:16.0000] <MikeSmith>
「The "fpc" binary on OS X always has and for the foreseeable future always will generate 32 bit code by default (both on Intel and PowerPC systems). If you want 64 bit code, use "fpc -Px86_64" or ppcx64.

[03:09:03.0000] <annevk>
30 bugs https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=HTML&product=WHATWG&status_whiteboard=[good first bug]&status_whiteboard_type=substring

[03:09:09.0000] <annevk>
seems like a good start

[03:13:44.0000] <hsivonen>
do I understand correctly that the HTML spec switch from a build tool written in Python (anolis) to a build tool written in Free Pascal (wattsi) and in order to make the switch, Hixie implemented infrastructure like UTF-8 strings, HTML parsing and JSON parsing in Free Pascal?

[03:13:52.0000] <hsivonen>
s/switch/switched/

[03:14:44.0000] <annevk>
hsivonen: I think so

[03:15:20.0000] <hsivonen>
annevk: I see. Not a development paths I'd have recommended.

[03:15:59.0000] <hsivonen>
If you rewrite the world, do it in Rust.

[03:16:43.0000] <annevk>
That would be pretty cool, something like Bikeshed, but in Rust, so it's fast

[03:17:22.0000] <annevk>
I suppose eventually Rust will have enough infrastructure to port certain things

[03:18:19.0000] <MikeSmith>
annevk: thanks for doing https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=HTML&list_id=59317&product=WHATWG&status_whiteboard=%5Bgood%20first%20bug%5D&status_whiteboard_type=substring

[03:18:28.0000] <MikeSmith>
hsivonen: yeah your summary is correct

[03:18:31.0000] <jgraham>
Well Rust already has UTF8 strings, HTML Parsing and JSON parsing

[03:19:10.0000] <MikeSmith>
I agree that if somebody were to write something like this now, Rust would seem like the better way to do it

[03:19:46.0000] <MikeSmith>
but, well, soembody else didn't write it

[03:20:00.0000] <jgraham>
I think mostly Hixie used free pascal because he likes pascal

[03:20:01.0000] <MikeSmith>
and the wattsi code is actually pretty nice

[03:20:46.0000] <MikeSmith>
yeah, and he writes pascal pretty good, as far as I can see

[03:20:58.0000] <MikeSmith>
wattsi seems very fast to me

[03:21:05.0000] <jgraham>
(but also because http://ian.hixie.ch/programming/ which is not a great approach to picking a programming language)

[03:21:08.0000] <MikeSmith>
for what it's doing

[03:22:26.0000] <MikeSmith>
jgraham: you mean, just ranking the language by where the first letter of their name occurs in alphabetical order?

[03:22:35.0000] <MikeSmith>
I kind of like that ranking

[03:22:59.0000] <MikeSmith>
just don't know if it's reverse-sorted

[03:23:12.0000] <jgraham>
:p

[03:23:13.0000] <MikeSmith>
but I choose to assume it's from worst to best

[03:23:16.0000] <MikeSmith>
heh :)

[03:23:34.0000] <MikeSmith>
anyway, it puts Python at the top!

[03:23:43.0000] <MikeSmith>
or else C

[03:23:45.0000] <jgraham>
And Rust would be even topper

[03:23:51.0000] <MikeSmith>
yes!

[03:23:59.0000] <MikeSmith>
it really works!

[03:24:16.0000] <MikeSmith>
I'm going to inject Rust into that page

[03:24:27.0000] <MikeSmith>
since Hixie is serving it insecurely

[03:24:42.0000] <MikeSmith>
/me goes back to trying to write a wattsi patch

[03:28:48.0000] <hsivonen>
Hixie's Programming Languages page seems wrong about Java when it claims no language support for enumeration

[03:29:32.0000] <hsivonen>
also weird that Automatic memory management is colorless but Execution makes a value judgment against VMs

[03:29:41.0000] <jgraham>
I think the more fundamental wrongness is judging a language as a checklist of features

[03:30:00.0000] <hsivonen>
that, too

[03:30:23.0000] <Ms2ger>
Does the checklist have UTF8 strings, HTML Parsing and JSON parsing? :)

[03:33:19.0000] <nox>
Where is that?

[03:33:21.0000] <nox>
Sounds fun.

[03:33:26.0000] <MikeSmith>
/me learns how to disable runtime range checks in Free Pascal

[03:33:29.0000] <nox>
Oh god.

[03:33:42.0000] <nox>
So horrible.

[03:33:46.0000] <MikeSmith>
heh

[03:35:38.0000] <nox>
jgraham: And Rust's HTML parsing improved quite a bit yesterday. :)

[03:36:30.0000] <jgraham>
nox: Oh?

[03:37:15.0000] <nox>
jgraham: 10 PRs landed, h5e even parses <isindex> now.

[03:37:22.0000] <jgraham>
Nice!

[03:41:11.0000] <annevk>
Another clean merge

[03:44:44.0000] <MikeSmith>
/me peruses the commit log

[04:12:54.0000] <annevk>
I wonder if <isindex> is still implemented in all browsers

[04:22:29.0000] <mkwst>
annevk: I dropped it from Chrome. I think folks from Opera and Mozilla were sad about that.

[04:35:45.0000] <MikeSmith>
mkwst: did you ever find an acceptable (context-appropriate) synonym for the world "credential"?

[04:36:44.0000] <mkwst>
nope.

[04:36:57.0000] <mkwst>
I'm calling them credentials until someone tells me to stop.

[04:37:59.0000] <MikeSmith>
SGTM

[04:41:01.0000] <mkwst>
MikeSmith: The only thing I can think of would be to rename the API to something like `navigator.auth`, which would cover the three things I care about, and exclude the many things I don't. That said, "auth" seems to promise a bit more than I think I can deliver. *shrug*

[04:53:13.0000] <MikeSmith>
mkwst: yeah I'd say you already went above and beyond on trying to address the naming concern (and the imagined confusion it might cause for actual devs)

[04:53:53.0000] <mkwst>
MikeSmith: I'd say the same! But whatever. I don't want to stop on their namespace if there's a reasonable think I can call the thing I want to build that doesn't use the word they love so much and have defined so strangely.

[04:54:08.0000] <MikeSmith>
well

[04:54:18.0000] <MikeSmith>
they don't own any namespace on this

[04:54:30.0000] <MikeSmith>
despite what they might try to imply/assert

[04:54:37.0000] <mkwst>
No, of course not. But, politeness etc.

[04:54:41.0000] <MikeSmith>
sure

[04:55:13.0000] <mkwst>
They wrote their strange spec before I made mine public, so. *shrug* I'm friendly. :)

[04:55:35.0000] <MikeSmith>
we clearly need to version words

[04:56:07.0000] <MikeSmith>
"You mean 'credentials2', right? I'm talking about 'credentials1'."

[05:12:06.0000] <mkwst>
well, we have that. "I'm talking about https://w3c.github.io/webappsec/specs/credentialmanagement/#credentials, you're talking about https://web-payments.org/specs/source/identity-credentials/#dfn-credential."

[05:22:21.0000] <MikeSmith>
hahah

[05:24:40.0000] <annevk>
You can instantly tell who's using ReSpec

[05:26:08.0000] <MikeSmith>
mkwst: just bind to those URIs some arbitrary prefixes that require looking back somewhere else in the conversation/world to resolve, and you have an world-class extensible solution to your problem

[05:26:09.0000] <annevk>
SimonSapin: how do you say "simply reverse engineering browsers." in French?

[05:26:18.0000] <annevk>
/me wants to reply to https://twitter.com/Titi_Alone/status/639024422049984512

[05:27:09.0000] <annevk>
hsivonen: https://github.com/whatwg/html/pull/66 made the ISO-2022-JP thing a should, otherwise addressed your comments

[05:28:51.0000] <caitp>
does the URI spec really require you to parse IPv4 with each byte encoded as octal or hex?

[05:29:19.0000] <annevk>
caitp: URL does, URI doesn't

[05:29:56.0000] <MikeSmith>
hey it's caitp (long time no see)

[05:30:00.0000] <annevk>
(URI is obsolete though)

[05:30:32.0000] <caitp>
I use them interchangeably for some reason

[05:30:39.0000] <MikeSmith>
for those who like stuff related to range checks in Python: https://github.com/whatwg/wattsi/pull/1

[05:32:50.0000] <annevk>
s/Python/Pascal/?

[05:32:55.0000] <annevk>
Assigned to Hixie

[05:33:11.0000] <MikeSmith>
thanks

[05:33:22.0000] <MikeSmith>
yeah, Freudian slip

[05:34:18.0000] <MikeSmith>
anyway I guess now that we have a "wattsi as a service", that PR is somewhate moot. And Hixie might reject it. And if he does I won't be unhappy. And I will at least have done the Right Thing by trying actually fix it.

[05:59:00.0000] <annevk>
johnme: thank you!

[05:59:14.0000] <annevk>
johnme: just noticed that's your first commit too, great

[06:06:43.0000] <MikeSmith>
there's an attr() function in CSS now? https://github.com/w3c/css-validator/issues/24 (I guess I vaguely recall)

[06:07:28.0000] <MikeSmith>
ah, since 2.1 (dinnet now)

[06:08:24.0000] <darobin>
yeah, but it hasn't been reliably implemented, at least it didn't use to be, haven't checked in a while

[06:08:54.0000] <MikeSmith>
hey darobin

[06:08:55.0000] <MikeSmith>
ok

[06:08:59.0000] <darobin>
hey man

[06:12:14.0000] <MikeSmith>
darobin: I've decided to switch over to focusing most of my time to debugging Free Pascal code from now on

[06:12:30.0000] <darobin>
MikeSmith: that sounds like a precious life skill

[06:13:21.0000] <darobin>
somehow I get the feeling that if I hadn't just bailed I might have found myself drawn into the same...

[06:13:28.0000] <darobin>
good instinct, there

[06:14:37.0000] <jgraham>
MikeSmith: Don't knock it, if you believe http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Object Pascal is like the 14th most popular programming language

[06:15:09.0000] <MikeSmith>
/me looks

[06:15:35.0000] <jgraham>
/me tries not to draw attention to the word "if" in that sentence

[06:16:17.0000] <MikeSmith>
I like Hixie's ranking-by-alphabet much better.

[06:16:36.0000] <MikeSmith>
that listing overcomplicates things with arbitrary criteria

[06:18:42.0000] <jgraham>
Hixie's ranking probably overstates how good VisualBasic is, however :p

[06:26:49.0000] <gsnedders>
MikeSmith: CSS 2.1 attr() is widely supported. CSS 3 attr() isn't.

[06:28:36.0000] <johnme>
annevk: thanks for reviewing :)

[06:31:44.0000] <MikeSmith>
jgraham: :) zsh shell scripting #1!

[06:31:48.0000] <MikeSmith>
gsnedders: ah OK

[06:58:36.0000] <JakeA>
annevk: trying to pick a day for the next sw f2f. Ted wasn't keen on using the plenary day, that leaves Monday or Tuesday. I imagine either of these will cause clashes. Any preference?

[07:06:22.0000] <annevk>
JakeA: either is fine with me

[07:17:39.0000] <SimonSapin>
annevk: a translation of "reverse engineering" exists, but no-one uses it. I replied to that tweet

[07:18:09.0000] <annevk>
ta

[07:51:48.0000] <wanderview>
annevk: mkwst: gecko supports request.formData()

[07:51:59.0000] <wanderview>
not sure which version it was implemented in, though

[08:49:49.0000] <darobin>
a CORS-related error is never detectable from either XHR or Fetch, right?

[08:59:44.0000] <annevk>
darobin: correct

[08:59:58.0000] <darobin>
yeah, the PouchDB people are on crack

[09:00:23.0000] <darobin>
annevk: it seems to be a common misconception that status:0 means CORS error; I guess that's because devs never see other network errors

[09:01:14.0000] <annevk>
darobin: heh, that just means "network error"

[09:01:22.0000] <annevk>
and there's more and more reasons you can get them, too

[09:01:56.0000] <darobin>
annevk: yeah, right — but since in regular development contexts you never get any except when you forget to switch CORS on, people assume this

[09:02:22.0000] <darobin>
one more reason against numeric error codes :)

[09:02:55.0000] <annevk>
Everything folks believe about CORS is likely wrong. Such a sad protocol.

[09:03:01.0000] <darobin>
lol

[09:03:11.0000] <annevk>
And yes, numeric codes are not great...

[09:04:33.0000] <annevk>
wasm is a pretty exciting "binary" format where all the numbers are variables coming from a map at the start of the file that maps feature strings to these variables

[09:04:55.0000] <annevk>
Rather than having standardized opcodes

[09:06:16.0000] <Ms2ger>
annevk, why is createDocument black and createHTMLDocument orange in https://dom.spec.whatwg.org/#dom-domimplementation-createdocument ?

[09:07:16.0000] <annevk>
Ms2ger: the Bikeshed conversion...

[09:07:28.0000] <annevk>
Ms2ger: it removed all the <code> inside <dfn>

[09:07:33.0000] <Ms2ger>
Fun

[09:07:39.0000] <annevk>
In a way

[09:11:37.0000] <ccardona-work>
Good morning/afternoon/evening whatwg crew o/

[09:15:37.0000] <annevk>
ccardona-work: evening

[09:16:05.0000] <daleharvey>
darobin: cheers for the vote of confidence, we only use it to inform the user of a very regular problem they come up against

[09:17:55.0000] <daleharvey>
/me sees the issue on github

[09:18:10.0000] <annevk>
daleharvey: pointer?

[09:18:21.0000] <daleharvey>
https://github.com/pouchdb/pouchdb/pull/4190

[09:19:14.0000] <annevk>
daleharvey: ta

[09:19:50.0000] <annevk>
daleharvey: I guess if that's the most common error for pouchdb saying that, while also saying it could be something else might be the best way forward

[09:20:42.0000] <daleharvey>
yeh the wording can be changed, it does say 'seems to indicate' but could be a little clearer

[09:21:40.0000] <annevk>
daleharvey: you could also not use it for same-origin requests, though redirects make that tricky

[09:22:03.0000] <darobin>
daleharvey: sorry if "on crack" came across as maybe a little brisk, it's just an expression :)

[09:22:31.0000] <darobin>
daleharvey: another improvement is that, in this case, the abort is actually triggered by Pouch

[09:22:41.0000] <darobin>
so you know it's a timeout

[09:23:07.0000] <ccardona-work>
annevk: o/

[09:26:59.0000] <darobin>
daleharvey: I've pointed out the timeout source in the bug

[09:33:12.0000] <ato>
annevk: Existing WebDriver implementations have special instructions for how to handle showModalDialog().  HTML says it’s in the process of being removed, but I wonder what your thoughts are on whether our spec should say anything about them, considering it is directed at primarily new implementations.

[09:34:28.0000] <ato>
Does anyone know if Edge implements it?

[09:34:33.0000] <Ms2ger>
Allegedly not

[09:36:12.0000] <ato>
If it’s not in Gecko, Chrome, and Edge I guess I have my answer there, since Microsoft isn’t doing a WD implementation for IE11.

[09:38:36.0000] <Ms2ger>
ato, so what kind of instructions are those?

[09:39:26.0000] <ato>
Ms2ger: Ways of interacting and dismissing the dialogue, and some behaviour to automatically dismiss them if a top-level browsing context is discarded.

[09:40:04.0000] <Ms2ger>
Aha

[09:41:53.0000] <Domenic>
ato: it is not in Chrome or Edge or mobile Safari. Gecko is the only remaining major implementer.

[09:42:31.0000] <ato>
Domenic: And in Gecko it’s doesn’t work in Nightly anymore (even if the deprecation bug is still open).

[09:45:21.0000] <Domenic>
can someone test desktop safari for me actually? http://www.thesaabsite.com/js/safari-5.1-bugfix-test.html

[09:51:01.0000] <astearns>
Domenic: Mac desktop 8.0.8?

[09:51:11.0000] <Domenic>
astearns: sure

[09:51:39.0000] <astearns>
OK works in both. Cancel for prompt clears field, Cancel on showModalDialog sets to "<null>"

[09:51:45.0000] <astearns>
prompt comes up much quicker

[09:51:56.0000] <Domenic>
fascinating

[09:52:02.0000] <Domenic>
so they really did only kill it on mobile

[09:59:19.0000] <annevk>
"I sent a more detailed e-mail to the TAG where I think the discussion has per force moved to" going to continue to stay out of this

[09:59:44.0000] <smaug____>
IIRC we have so high usage numbers for showModalDialog that we can't really remove it real soon

[10:00:13.0000] <annevk>
smaug____: our numbers are different from Chrome?

[10:00:27.0000] <annevk>
smaug____: did all the existing Chrome users switch to Firefox?

[10:04:50.0000] <smaug____>
would be better to ask mrbkap

[10:05:25.0000] <smaug____>
but, IIRC, the idea was to not implement it for e10s, but the usage was high enough that the decision changed

[10:08:06.0000] <smaug____>
(also, showModalDialog hasn't been an issue for Gecko from implementation point of view, which is why there hasn't be rush on removing it)

[10:29:20.0000] <smaug____>
mounir: I assume blink is ok to change its presentation API implementation

[10:29:25.0000] <smaug____>
quite a bit perhaps

[10:29:36.0000] <smaug____>
perhaps it hasn't shipped yet

[10:32:40.0000] <smaug____>
so silly over-Promise-fying

[11:07:40.0000] <MikeSmith>
mkwst: it seems like http-equiv="Content-Security-Policy" needs to be added to the allowed values for http-equiv in the spec at https://html.spec.whatwg.org/multipage/semantics.html#pragma-directives

[11:08:27.0000] <mkwst>
MikeSmith: Didn't I add that?

[11:08:37.0000] <MikeSmith>
oh

[11:08:39.0000] <MikeSmith>
/me looks

[11:09:06.0000] <mkwst>
Ah. I have a local branch on my work computer where I've mostly added that. You're not crazy, I'm crazy. :)

[11:09:08.0000] <MikeSmith>
I don't find it in the spec, not

[11:09:13.0000] <MikeSmith>
heh

[11:09:38.0000] <MikeSmith>
yeah I would have been surprised if you weren't on top of it already :)

[11:09:46.0000] <mkwst>
Yes. We need to add that. Basically copy/pasting the text from https://w3c.github.io/webappsec/specs/content-security-policy/#delivery-html-meta-element.

[11:09:47.0000] <MikeSmith>
even if it is just locally

[11:09:57.0000] <MikeSmith>
yes

[11:10:04.0000] <MikeSmith>
people are using it

[11:10:23.0000] <MikeSmith>
see http://stackoverflow.com/questions/32359701/is-multiline-meta-content-value-alowed

[11:10:46.0000] <MikeSmith>
or see my answer there at http://stackoverflow.com/a/32359837/441757

[11:16:38.0000] <mkwst>
Yes. It's the easiest way to deploy for some folks. github Pages, for instance.

[11:17:26.0000] <mkwst>
Would you mind filing a spec bug and assigning it to me so I remember to unmonkeypatch that bit tomorrow?

[11:21:44.0000] <MikeSmith>
hai

[11:27:07.0000] <MikeSmith>
hmm apparently it won't let me assign it to you

[11:27:50.0000] <MikeSmith>
we only have one team associated with this repo and that team doesn't have you as a member

[11:28:05.0000] <MikeSmith>
/me will figure something out

[11:28:49.0000] <mkwst>
*shrug* Whatever. I don't need superpowers. :) I see the bug, and I'll throw out a PR tomorrow. Thanks!

[11:32:06.0000] <MikeSmith>
cheers

[11:40:46.0000] <gsnedders>
hmm, I'm getting an internal server error from bugs.webkit.org o_O

[12:46:30.0000] <annevk>
yet more icons for https://github.com/whatwg/html/commits \o/

[12:50:55.0000] <annevk>
MikeSmith: if you give someone read access, can you assign things to them?

[12:51:45.0000] <annevk>
MikeSmith: if that was feasible we could have a large read access team for html to make these kind of things easier; not sure I want to enlarge the group of folks that has push access at this point

[12:53:01.0000] <Domenic>
On GitHub? Hmm we can test this.

[12:53:10.0000] <Domenic>
I was thinking similar thoughts

[12:56:54.0000] <Domenic>
annevk: yes, it works

[12:57:04.0000] <Domenic>
annevk: a bit annoying you can't give it to anyone in the org

[12:57:55.0000] <Domenic>
annevk: I made https://github.com/orgs/whatwg/teams/html feel free to either add a bunch of people or merge it with https://github.com/orgs/whatwg/teams/contributors (which you would need to add read access to html on) or whatever

[13:01:17.0000] <annevk>
Domenic: I'm not sure why we have the latter team still

[13:01:53.0000] <annevk>
/me adds mkwst

[13:02:00.0000] <annevk>
(to html)

[13:02:05.0000] <mkwst>
Hrm?

[13:02:23.0000] <annevk>
mkwst: see GitHub invites, it's mostly so we can assign issues to you :-P

[13:03:50.0000] <mkwst>
SGTM.

[13:04:26.0000] <Domenic>
annevk: I kind of thought of it as basically for situations like this. we'd add everyone in the org and add read access to every spec\

[13:04:41.0000] <mkwst>
I am now a member of WHATWG, but I can't self-assign https://github.com/whatwg/html/issues/88.

[13:04:44.0000] <Domenic>
annevk: but let's kill it and use html then. if we have another spec we want to do it for we can just rename the team

[13:05:15.0000] <Domenic>
mkwst: hmm yeah I think only people with push access can assign. Kind of lame.

[13:05:33.0000] <mkwst>
No worries. Someone will assign it to me, I'm sure.

[13:08:13.0000] <mkwst_zzz>
Night all.

[14:34:11.0000] <gsnedders>
Trying to sort out the divergences of the Blink fork of html5lib-tests…

[14:34:27.0000] <gsnedders>
Anyone want to tell me what "<div><a><b><div><div><div><div><div><div><div><div><div><div></a>" should result in, with any confidence?

[14:34:37.0000] <gsnedders>
AAA limit test!

[14:40:48.0000] <jgraham>
gsnedders: Whatever gecko does, or we change the spec :p

[14:42:44.0000] <gsnedders>
OK, we seem to have interop at least

[14:42:51.0000] <gsnedders>
the Blink version of the test is just wrong

[14:42:54.0000] <gsnedders>
v. everyone

[14:48:03.0000] <nox>
gsnedders: Is that in html5lib-tests?

[14:48:24.0000] <nox>
Oh you said that. I can't read.

[15:08:27.0000] <mounir>
smaug____: what's the problem with presentation api?

[15:08:47.0000] <smaug____>
just a bit over-engineered API

[15:08:56.0000] <smaug____>
too much Promise usage etc

[15:09:05.0000] <smaug____>
I'll file some bugs

[15:09:19.0000] <mounir>
smaug____: you might be too late to the game but feel free to file bugs

[15:09:19.0000] <smaug____>
not the first time I've seen overuse of Promises

[15:09:26.0000] <smaug____>
mounir: how so?

[15:09:33.0000] <smaug____>
it is not stable or anything

[15:09:44.0000] <mounir>
people have been working on this api for two years

[15:10:00.0000] <mounir>
not sure how open they are for cosmetic changes at that point

[15:10:08.0000] <smaug____>
People have worked on DOM APIs for decades,and still changing it ;)

[15:10:11.0000] <mounir>
but again, file bugs, I'm pretty sure anything reasonable will be considered

[15:10:29.0000] <smaug____>
mounir: the API has changed recently, and apparently the spec hasn't been reviewed

[15:10:30.0000] <mounir>
smaug____: I doubt people are making backward incompatible changes ;)

[15:10:41.0000] <mounir>
smaug____: define "reviewed" :)

[15:10:59.0000] <smaug____>
well, reviewed as "is it implementeable"

[15:11:09.0000] <smaug____>
implementable

[15:11:20.0000] <mounir>
smaug____: Mozilla is implementing that

[15:11:21.0000] <smaug____>
like there are some mistakes in webidl etc

[15:11:28.0000] <smaug____>
mounir: I know, I'm reviewing that work

[15:11:31.0000] <mounir>
smaug____: and unless something comes up, Chrome will ship that in the next Beta

[15:13:11.0000] <smaug____>
mounir: chrome has shipped plenty of unstable APIs, like shadow dom ;)

[15:13:49.0000] <mounir>
smaug____: I guess

[15:18:51.0000] <smaug____>
/me wonders what chrome does when (new PresentationSessionConnectEvent("")).session is executed in the context where PresentationSessionConnectEvent is available

[15:19:13.0000] <smaug____>
that is a case broken in the spec, as an example

[15:19:28.0000] <smaug____>
looks like broken also in blink source cod

[15:19:31.0000] <smaug____>
e

[16:57:30.0000] <nox>
I think the adopting steps need to be run recursively in https://dom.spec.whatwg.org/#concept-node-adopt-ext.


2015-09-03
[17:19:19.0000] <nox>
https://github.com/whatwg/dom/pull/66/files

[17:19:24.0000] <nox>
Err, https://github.com/whatwg/dom/pull/66

[18:09:10.0000] <MikeSmith>
/me wonders if Domenic and annevk got things worked out as far at the teams stuff for the repo; seems like it

[18:33:25.0000] <Domenic>
yepyep

[18:37:30.0000] <Domenic>
The problem with all this crazy tooling is that if I wanted to extend it I'd start writing node.js code

[18:37:41.0000] <Domenic>
But we already have like 4 languages and prereqs

[18:37:47.0000] <Domenic>
Adding a fifth seems bad

[18:39:10.0000] <Domenic>
E.g. Sebmaster is basically doing https://github.com/whatwg/html/issues/55 in node already for independent reasons (he's writing a generic spec Web IDL scraper)

[18:39:33.0000] <Domenic>
I guess it should really be done in wattsi though since wattsi already has a parsed representation of the document

[19:05:38.0000] <MikeSmith>
I'd be willing to work on extending the wattsi code if we really thought that was the best way to do it

[19:06:02.0000] <MikeSmith>
But it seems like it might not be best, I dunno

[19:07:13.0000] <MikeSmith>
I personally would rather we rewrote it all in Rust 😀

[19:09:14.0000] <MikeSmith>
Anyway, I have a question about document.evaluate

[19:09:54.0000] <MikeSmith>
I'm wondering why the current normative spec for it is

[19:10:59.0000] <MikeSmith>
and if the answer is, the DOM3 spec, then that seems less than ideal

[19:11:50.0000] <MikeSmith>
seems like it should be re-specced in  a modern

[19:12:18.0000] <MikeSmith>
*modern spec

[19:32:13.0000] <Domenic>
Hmm. It doesn't show up in https://dom.spec.whatwg.org/#dom-core-changes

[19:34:54.0000] <Domenic>
Oh jeez it's in prose  In a DOM implementation which supports the XPath 3.0 feature, as described above, the XPathEvaluator interface will be implemented on the same object which implements the Document interface

[19:35:35.0000] <Domenic>
MikeSmith: my thinking is that DOM is not meant to subsume DOM 3 XPath, just DOM 3 Core.

[19:36:03.0000] <Domenic>
There's not too much there though, it could probably be subsumed and modernized

[19:37:47.0000] <MikeSmith>
Yeah

[19:39:10.0000] <MikeSmith>
devs and libraries do actually use it, so it would be nice to actually have a good spec for it

[19:39:32.0000] <MikeSmith>
WebDriver relies on it

[19:40:22.0000] <MikeSmith>
or at least WebDriver implementations/libraries Do

[19:40:41.0000] <MikeSmith>
through an abstraction

[19:41:03.0000] <Domenic>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/xml/XPathEvaluator.idl&q=xpath%20idl&sq=package:chromium&l=24 is interesting

[19:41:17.0000] <MikeSmith>
/me looks

[19:42:59.0000] <MikeSmith>
dang that UI is makes it hard to read on mobile

[19:43:06.0000] <MikeSmith>
frame layout

[19:43:19.0000] <MikeSmith>
/me rotates

[19:43:29.0000] <Domenic>
https://www.chromestatus.com/metrics/feature/timeline/popularity/297 https://www.chromestatus.com/metrics/feature/timeline/popularity/295 https://www.chromestatus.com/metrics/feature/timeline/popularity/296 usage stats... could in theory remove createExpression?

[19:44:08.0000] <Domenic>
Which would be nice because then we could kill XPathExpression entirely

[19:44:53.0000] <MikeSmith>
/me looks more

[19:46:52.0000] <MikeSmith>
Domenic: yes

[20:45:45.0000] <annevk>
Domenic: MikeSmith: ideally we would have team permissions for creating and pushing to branches other than master, and indeed also assigning etc.

[20:45:54.0000] <annevk>
Domenic: MikeSmith: with just master controlled by a small set of folks

[20:46:01.0000] <annevk>
Domenic: but alas

[20:46:08.0000] <annevk>
I guess we could ask for that...

[21:05:31.0000] <MikeSmith>
annevk: if by "we could ask for that" you mean, ask github to add that feature, then I agree. But that said, even if they say Yeah and think it's the greatest idea in the world, it would be like 6 months at least before it's actualy deployed

[21:05:56.0000] <MikeSmith>
so in practice that doesn't solve any problem for us

[21:06:23.0000] <MikeSmith>
(plus, you're up really eearly again)

[21:06:29.0000] <annevk>
If I could solve all my problems within six months by sending an email...

[21:06:34.0000] <MikeSmith>
haha

[21:07:00.0000] <annevk>
We're going to bed earlier as well, so it evens out

[21:07:06.0000] <MikeSmith>
ok

[21:07:12.0000] <MikeSmith>
so anyway

[21:07:12.0000] <botie>
so is probably TabAtkins going to do the geocities look again?

[21:07:19.0000] <MikeSmith>
document.evaluate

[21:07:23.0000] <MikeSmith>
thoughts?

[21:07:53.0000] <annevk>
Well, I'm not opposed to specifying it, but it doesn't seem high priority

[21:07:55.0000] <MikeSmith>
e.g., fine to leave it as-is in DOM3 XPath

[21:07:57.0000] <MikeSmith>
oh

[21:07:59.0000] <MikeSmith>
ok

[21:08:00.0000] <MikeSmith>
yeah

[21:08:02.0000] <MikeSmith>
I guess so

[21:08:11.0000] <annevk>
Note that we have the DOM XPath wiki page that has more detail

[21:08:20.0000] <MikeSmith>
ah ok, will lok

[21:08:36.0000] <MikeSmith>
yeah I vaguely recalled there being something

[21:08:59.0000] <MikeSmith>
webdriver users rely on XPath very heavily

[21:09:17.0000] <MikeSmith>
but they don't care how it works under the hood, as long as it works

[21:09:48.0000] <MikeSmith>
so if we could replace what we have now with something that's modern and better that would be great too

[21:10:05.0000] <TabAtkins>
...why is botie talking to me?

[21:10:23.0000] <MikeSmith>
I mean, not just re-speccing it properly, but creating a new modern API

[21:11:33.0000] <MikeSmith>
TabAtkins: botie was apparently responding to me saying "so", and thinks "so" means "probably TabAtkins going to do the geocities look again"

[21:12:40.0000] <annevk>
MikeSmith: not sure about new APIs, that seems even less relevant now than it when that came up a decade ago or so

[21:12:47.0000] <MikeSmith>
/me reads https://wiki.whatwg.org/wiki/DOM_XPath

[21:12:50.0000] <TabAtkins>
Sure, that makes sense

[21:12:56.0000] <annevk>
MikeSmith: especially since nobody is interested in extending the XPath language

[21:13:08.0000] <annevk>
(when it comes to the web platform anyway)

[21:14:06.0000] <MikeSmith>
annevk: I would think so as well if I didn't see a dozen questions a day on StackOverflow who are trying to get stuff done with webdriver and trying to figure out XPath expressions to let them do what they need

[21:14:33.0000] <MikeSmith>
which is typically, "I need to make webdriver emulate a click on this specific element"

[21:14:34.0000] <annevk>
Can't WebDriver provide a proprietary API then? Or a small wrapper library?

[21:15:03.0000] <MikeSmith>
why a proprietary API? WebDriver is a standard

[21:21:15.0000] <MikeSmith>
annevk: and webdriver already puts a wrapper/abstraction around the XPath stuff. All webdriver implementations have something called findElementByXPath or something like that

[21:21:26.0000] <MikeSmith>
I guess it's standard actually

[21:21:46.0000] <MikeSmith>
/me should read the spec more since he's nominally in charge of that WG

[21:22:00.0000] <MikeSmith>
it returns a thing called WebElement

[21:23:30.0000] <MikeSmith>
anyway it seems to me there's plenty of evidence that WebDriver is solving real problems. And in practice right now WebDriver users rely very heavily on XPath, so XPath is solving a real problem for them and helping them get real work done

[21:24:26.0000] <MikeSmith>
admittedly their XPath usage eventually could be replaced by some other addressing mechanism/API

[21:24:56.0000] <MikeSmith>
I think their tools actually already provide some method that allows doing it with Selectors

[21:25:01.0000] <terinjokes>
/me raises hand as WebDriver user who's used years of libxml experience to craft XPath

[21:25:16.0000] <MikeSmith>
hey terinjokes

[21:25:55.0000] <MikeSmith>
my impression is that despite having Selectors support as an alternative, very few webdriver devs actually use it

[21:26:08.0000] <MikeSmith>
/me shuts up for now

[21:26:19.0000] <MikeSmith>
/me changes his mind

[21:27:04.0000] <MikeSmith>
annevk: about "nobody is interested in extending the XPath language", it arguably doesn't need extending. XPath 1.0 works fine as far as webdriver users go at least

[21:27:07.0000] <terinjokes>
i've used xpath to select a specific element (i want element with class "x" that's in the third div with class "y" with the parent C, though obviously written backwards from this)

[21:27:25.0000] <terinjokes>
which might be possible as a selector, but I don't know how to do it

[21:28:00.0000] <MikeSmith>
I've not seen many normal people saying that XPath 1.0 needs to be extended to do what they need

[21:28:36.0000] <MikeSmith>
but maybe I'm not aware of other deficiencies that are causing any problems we actually care about

[21:28:41.0000] <MikeSmith>
TabAtkins: yeah

[21:28:44.0000] <MikeSmith>
oofs

[21:29:03.0000] <MikeSmith>
s/TabAtkins/terinjokes/ there

[21:29:11.0000] <MikeSmith>
/me shuts up again

[21:29:43.0000] <TabAtkins>
I KEEP GETTING MENTIONED FOR NO REASON

[21:30:19.0000] <MikeSmith>
hahah

[21:30:31.0000] <MikeSmith>
botie: bug TabAtkins about something

[21:30:32.0000] <botie>
MikeSmith: i'm not following you...

[21:30:32.0000] <boogyman>
you could always change your nick to NotTabAtkins

[21:30:59.0000] <TabAtkins>
GODDAMMIT

[21:31:14.0000] <terinjokes>
MikeSmith: my understanding is that botie only responds in a useful manner to "so"

[21:32:33.0000] <MikeSmith>
so what?

[21:32:34.0000] <botie>
it has been said that so is TabAtkins going to do the geocities look again?

[21:32:45.0000] <MikeSmith>
oh man that's annoying

[21:32:51.0000] <MikeSmith>
will delete that now

[21:33:01.0000] <MikeSmith>
in the mean time https://www.w3.org/TR/webdriver/#element-location-strategies

[21:33:10.0000] <TabAtkins>
OMIGOD BOTIE SHUT UP

[21:33:53.0000] <MikeSmith>
https://www.w3.org/TR/webdriver/#findelements & https://www.w3.org/TR/webdriver/#findelement

[21:41:06.0000] <terinjokes>
i think i might steal this phrase in my future "specs": "However, in the absence of another specification actually defining this, here are some guidelines for implementors"

[21:50:24.0000] <MikeSmith>
hahah

[21:50:55.0000] <MikeSmith>
yeah I remember now why I avoided reading that spec in detail

[21:51:20.0000] <MikeSmith>
anyway jgraham and Andreas Tolfsen have been helping on that spec and it's getting much better

[21:55:03.0000] <MikeSmith>
terinjokes: oh wait, what spec were you quoting there?

[21:55:58.0000] <terinjokes>
MikeSmith: the w3 draft version of html. it's how the non-normative sections about XSLT and <script> and <template> begin

[21:56:17.0000] <MikeSmith>
ah ok

[21:56:36.0000] <annevk>
MikeSmith: that XPath is fine for WebDriver doesn't mean there should be a better API in browsers I think

[21:56:42.0000] <terinjokes>
i got linked to from the WebDriver spec somehow

[21:57:47.0000] <MikeSmith>
botie, so is the word that comes before la

[21:57:48.0000] <botie>
...but so is TabAtkins going to do the geocities look again?...

[21:57:52.0000] <MikeSmith>
botie, no, so is the word that comes before la

[21:57:53.0000] <botie>
...but so is TabAtkins going to do the geocities look again?...

[21:57:56.0000] <MikeSmith>
fuck

[21:58:15.0000] <MikeSmith>
no, so is the word that comes before la

[21:58:23.0000] <MikeSmith>
botie, so is the word that comes before la

[21:58:23.0000] <botie>
...but so is TabAtkins going to do the geocities look again?...

[21:58:25.0000] <MikeSmith>
no, so is the word that comes before la

[21:59:56.0000] <MikeSmith>
annevk: yeah I suppose so

[22:16:01.0000] <MikeSmith>
so what?

[22:16:57.0000] <MikeSmith>
TabAtkins: I just deleted the entire "is"-association DB that botie was using

[22:17:44.0000] <MikeSmith>
I guess I should just turn it off but I don't want to spend 30 minutes or whatever it would take to do that atm

[22:26:45.0000] <annevk>
Ugh, error: did you mean `--ff-only` (with two dashes ?)

[22:26:52.0000] <annevk>
Pedantic software...

[22:37:16.0000] <TabAtkins>
MikeSmith: Haha, thanks

[22:54:52.0000] <MikeSmith>
annevk: meta note: for stuff like https://github.com/whatwg/html/commit/db33a45abcfddb6c17605ed64d474d1489090335#commitcomment-13039312 I think the best workflow would be that you just make those changes directly on the branch yourself. Since they are relatively minor and seem uncontroversial.

[22:55:17.0000] <MikeSmith>
annevk: and since it takes less time to actually do it than it does to have a discussion about it

[22:55:55.0000] <annevk>
Yeah I suppose, since we just started it's still a bit unclear what everyone cares strongly about

[22:56:12.0000] <MikeSmith>
yeah true

[22:56:18.0000] <MikeSmith>
never know sometimes

[22:56:47.0000] <MikeSmith>
that's part of why I try not to feel too strongly about anything (not that I always succeed)

[22:58:58.0000] <annevk>
MikeSmith: are you around for a while longer?

[22:59:05.0000] <annevk>
MikeSmith: wondering what "ln -s ../images .wattsi-output/multipage-html/" is in the build-script

[22:59:24.0000] <annevk>
MikeSmith: I realize it creates a link, but it does so from the current working directory seemingly

[22:59:45.0000] <MikeSmith>
annevk: I'm around for the rest of the day (hours and hours)

[23:00:04.0000] <MikeSmith>
I didn't know the build script did that

[23:00:08.0000] <MikeSmith>
/me looks

[23:04:59.0000] <MikeSmith>
annevk: that seems to me like what exatly

[23:05:12.0000] <MikeSmith>
*exactly what it should be doing

[23:05:19.0000] <MikeSmith>
that is, it's working as intended

[23:05:24.0000] <MikeSmith>
is it causing some problem for you?

[23:05:26.0000] <MikeSmith>
errors?

[23:05:37.0000] <annevk>
I'm just confused what is being linked

[23:05:55.0000] <annevk>
Is it going to the parent directory of html-build/?

[23:06:21.0000] <annevk>
Hmm, seems I have to go for a bit

[23:06:31.0000] <annevk>
Back in half an hour or so

[23:07:11.0000] <MikeSmith>
k

[23:07:15.0000] <MikeSmith>
I'll still be here

[23:07:18.0000] <annevk>
My tentative plan for today is to create .html/ as input directory and have .generated-html/ as output directory or some such. So not all the files are cluttered with the rest...

[23:07:27.0000] <MikeSmith>
hmm

[23:07:43.0000] <MikeSmith>
well my plan for today is to actually work on the build script

[23:07:50.0000] <MikeSmith>
so maybe we should work on it together when you have time

[23:08:07.0000] <MikeSmith>
I have time for the next 3.5 hours or so

[23:08:13.0000] <annevk>
Okay

[23:08:17.0000] <MikeSmith>
then I'm on the train for ~2 hours

[23:08:20.0000] <annevk>
I've been hacking on https://github.com/whatwg/html-build/issues/1

[23:08:25.0000] <MikeSmith>
ok

[23:08:32.0000] <MikeSmith>
/me looks

[23:08:43.0000] <annevk>
I fixed the bits that need to be done in html/, now I need to fix the bits in html-build/

[23:08:57.0000] <annevk>
I can upload the html/ branch now so you can have a look

[23:09:03.0000] <MikeSmith>
super

[23:09:56.0000] <MikeSmith>
yeah let's get this stuff done today if we can

[23:11:28.0000] <annevk>
MikeSmith: https://github.com/whatwg/html/commit/a262f1d23cb8990a4735436215a01f0f4892f1a1

[23:11:42.0000] <annevk>
Not a big change so far :-)

[23:12:01.0000] <annevk>
Gotta bring O to daycare and then I'll be back to do the remaining bits

[23:12:11.0000] <MikeSmith>
hai

[23:12:32.0000] <MikeSmith>
will be here and will be looking at it all in the mean time

[23:14:08.0000] <MikeSmith>
/me sets aside the 2352 unread messages in his inbox for a while

[23:21:33.0000] <annevk>
MikeSmith: turns out I didn't have to today

[23:21:43.0000] <MikeSmith>
ah OK

[23:21:48.0000] <annevk>
MikeSmith: anyway, so the problem is that the build script removes the /multipage/ directory

[23:21:54.0000] <MikeSmith>
so, let's do this thing!

[23:21:56.0000] <MikeSmith>
annevk: OK

[23:21:59.0000] <MikeSmith>
yeah

[23:22:05.0000] <MikeSmith>
as it should I guess

[23:22:11.0000] <MikeSmith>
since it rebuilds it all

[23:22:22.0000] <annevk>
MikeSmith: whereas we want to just copy it from "input" and add wattsi output

[23:22:25.0000] <MikeSmith>
yeah

[23:25:46.0000] <MikeSmith>
annevk: looking at it all now

[23:27:01.0000] <MikeSmith>
annevk: so we want to keep .wattsi-output where it is now?

[23:27:20.0000] <MikeSmith>
or in our re-plan do we want to move it elsewhere?

[23:27:40.0000] <annevk>
MikeSmith: I think that's fine

[23:27:57.0000] <annevk>
MikeSmith: do you know why complete.html is copied and not simply moved to index?

[23:28:10.0000] <MikeSmith>
do not know but will look and find out

[23:28:46.0000] <MikeSmith>
before we start making further changes, I would like to land Domenic's patch for https://github.com/whatwg/html-build/pull/10

[23:28:50.0000] <MikeSmith>
OK?

[23:29:13.0000] <MikeSmith>
that's not going to break anything, but if we make changes it might break the merge-ability of that patch

[23:29:20.0000] <MikeSmith>
so I think it's better to land it now

[23:29:29.0000] <MikeSmith>
land=push

[23:30:00.0000] <annevk>
MikeSmith: seems fine if it works

[23:30:08.0000] <MikeSmith>
ok

[23:30:14.0000] <MikeSmith>
will do it in minute

[23:30:31.0000] <MikeSmith>
right now, still looking that thd build script

[23:31:08.0000] <annevk>
I think complete.html not being moved is some leftover we forgot to clean up

[23:31:13.0000] <annevk>
since it's identical to index

[23:31:19.0000] <MikeSmith>
so yeah, there is no good reason for complete.html to be cp'ed instead of mv'ed

[23:31:26.0000] <MikeSmith>
probably yeah

[23:32:51.0000] <annevk>
https://github.com/whatwg/html-build/pull/12

[23:34:10.0000] <annevk>
MikeSmith: so my idea was that we create .html; everything inside .html you need to ln yourself to whatwg/html

[23:34:26.0000] <MikeSmith>
manually?

[23:34:48.0000] <annevk>
MikeSmith: build.sh then copies .html to .html-build and we operate on that

[23:34:49.0000] <MikeSmith>
manually you'd need to run "ln -s" yourself?

[23:35:15.0000] <MikeSmith>
ah I thnk I see what you were saying

[23:35:20.0000] <annevk>
MikeSmith: well, perhaps we could check if it's in ../html or allow for a parameter

[23:35:27.0000] <MikeSmith>
yes

[23:35:31.0000] <MikeSmith>
exxactly

[23:35:37.0000] <MikeSmith>
so yeah, that's easy

[23:35:40.0000] <annevk>
MikeSmith: and we destroy .html-build at the start of build.sh

[23:35:47.0000] <MikeSmith>
ok

[23:36:02.0000] <annevk>
MikeSmith: both also need to be in .gitignore

[23:36:22.0000] <MikeSmith>
yeah sure that's really minor and can wait

[23:37:51.0000] <annevk>
MikeSmith: I'm still not sure what ln -s ../images .wattsi-output/multipage-html/ does though

[23:38:13.0000] <MikeSmith>
yeah me neither, after looking at it. But I'll figure it out

[23:38:15.0000] <annevk>
MikeSmith: does that mean that whenever you literally use "../images" it looks in the other place?

[23:38:34.0000] <MikeSmith>
right now though I'm getting a fatal build error: "can't find instance of attr-img-alt"

[23:38:35.0000] <annevk>
No that can't be it

[23:40:04.0000] <annevk>
MikeSmith: looking...

[23:41:01.0000] <annevk>
MikeSmith: I don't get that error

[23:41:35.0000] <MikeSmith>
annevk: yeah, may be due to my jacking around with my local wattsi yesterday

[23:41:44.0000] <MikeSmith>
will figure it out shortly

[23:53:17.0000] <MikeSmith>
... and, now hanging at "wget -o /dev/null -N http://www.w3.org/2003/entities/2007xml/unicode.xml"

[23:54:04.0000] <MikeSmith>
there's not good reason for that "-o /dev/null"

[23:54:50.0000] <MikeSmith>
it's not hanging.. just taking a long time, but because of that -o /dev/null there's no indicator of what's going on

[23:56:24.0000] <MikeSmith>
/me will later kill all of those redirects of stderr to /dev/null, and whatever else there may be that prevents useful debugging info from being emitted

[00:02:51.0000] <MikeSmith>
annevk: please pull

[00:03:15.0000] <MikeSmith>
so that you'll have the wattsi-service change

[00:03:39.0000] <MikeSmith>
and then also please rm your local wattsi executable

[00:03:53.0000] <MikeSmith>
so that we know for sure we're working from the same thing

[00:04:05.0000] <MikeSmith>
(and working from what we want others to use later)

[00:04:12.0000] <annevk>
okay

[00:07:42.0000] <annevk>
MikeSmith: I get "Local wattsi is not present; trying the build server..." while I have wattsi locally installed

[00:07:52.0000] <MikeSmith>
hmm my push didn't auto-close that PR and github still thinks the branch has unmerged changes. dunno what I did wrong but not going to worry about it since the changes are actually merged

[00:08:03.0000] <Domenic>
complete.html is a real URL that used to be a thing people linked to

[00:08:16.0000] <MikeSmith>
ah yeah

[00:08:16.0000] <Domenic>
If we move instead of copy, we'd need to add a redirect.

[00:08:17.0000] <MikeSmith>
true

[00:08:19.0000] <annevk>
Domenic: okay I'll add a redirect

[00:08:20.0000] <MikeSmith>
yes

[00:08:43.0000] <annevk>
That wattsi no longer works locally seems like a problem

[00:09:21.0000] <Domenic>
Ah damn that is bad

[00:09:33.0000] <Domenic>
I must have gotten my bash existence test wrong

[00:09:39.0000] <Domenic>
But also I need to sleep

[00:10:00.0000] <MikeSmith>
Domenic: no worries

[00:10:05.0000] <MikeSmith>
but yeah if [ -e "wattsi" ] is wrong

[00:10:27.0000] <MikeSmith>
it means, look for a wattsi file in the current dir, right?

[00:10:41.0000] <MikeSmith>
whereas, it might be somewhere else

[00:10:51.0000] <MikeSmith>
anyway, it's easy to fix

[00:10:59.0000] <Domenic>
I should have actually looked up -e

[00:11:13.0000] <MikeSmith>
bash stuff is arcane

[00:11:27.0000] <MikeSmith>
teh docs don't help terrifically much

[00:13:00.0000] <annevk>
Added a redirect to .htaccess, the relative URL should work as final argument since we have a new enough version of Apache

[00:14:39.0000] <MikeSmith>
Domenic: also I should have actually tested it for the wattsi-is-present-locally case before I pushed it

[00:15:12.0000] <MikeSmith>
(I just tested only the wattsi-isn't-present-locally case, by removing my wattsi)

[00:20:32.0000] <MikeSmith>
annevk: so, about that ln -s ../images .wattsi-output/multipage-html/

[00:20:44.0000] <MikeSmith>
as I said, that is doing what it's supposed to

[00:21:22.0000] <MikeSmith>
annevk: please do ls -al .wattsi-output/multipage-html/

[00:21:29.0000] <MikeSmith>
and see what it shows you

[00:27:05.0000] <annevk>
>No such file or directory

[00:28:29.0000] <annevk>
I don't have multipage-html generated...

[00:31:42.0000] <MikeSmith>
hmm, why not?

[00:32:26.0000] <MikeSmith>
/me looks at the branch to see if you changed something else

[00:32:52.0000] <annevk>
MikeSmith: I might have forgotten to ln some file I suppose

[00:33:27.0000] <cvrebert>
annevk: Do you mean "were you using a nightly build?" or "please re-test in a nightly build?" ?

[00:42:14.0000] <nox>
annevk: Can you help me a couple of minutes? Trying to figure if the spec forgot something for <template>.

[00:42:30.0000] <nox>
var template = document.createElement("template"); template.innerHTML = '<template id="t2">Some text</template>';

[00:42:51.0000] <nox>
I can't find in the spec how the set inner HTML can end up in `template`'s template contents.

[00:44:11.0000] <nox>
https://html.spec.whatwg.org/multipage/syntax.html#appropriate-place-for-inserting-a-node This scans the stack of open elements, but AFAICT in the fragment case, the only opened element is <html>, reading https://html.spec.whatwg.org/multipage/syntax.html#parsing-html-fragments.

[00:48:06.0000] <MikeSmith>
Domenic: is there any good reason for not having the build script automatically run the "svn checkout http://www.unicode.org/repos/cldr/trunk/common/main/ .cldr-data" step?

[00:48:44.0000] <MikeSmith>
because otherwise we should just have the build script do it, right?

[00:53:25.0000] <nox>
https://html.spec.whatwg.org/multipage/syntax.html#reset-the-insertion-mode-appropriately Oh I see, step 17.

[00:54:16.0000] <nox>
Ah no, misread step 17. Doesn't change stack of open elements.

[00:55:16.0000] <nox>
https://html.spec.whatwg.org/multipage/syntax.html#stack-of-open-elements says: 'In the fragment case, the stack of open elements is initialised to contain an html element that is created as part of that algorithm. (The fragment case skips the "before html" insertion mode.)'

[00:55:36.0000] <nox>
I'm pretty sure template fragments can't be parsed correctly with the current rules.

[00:56:53.0000] <nox>
I think that step 1 in https://html.spec.whatwg.org/multipage/syntax.html#appropriate-place-for-inserting-a-node should use "adjusted current node".

[01:00:02.0000] <MikeSmith>
this whole build script really should be just a makefile, as I think mkwst pointed out before

[01:00:08.0000] <MikeSmith>
but anyway, one thing at a time

[01:00:19.0000] <MikeSmith>
we can port it to make later

[01:02:25.0000] <cvrebert>
/me wait for butthurt Windows users to complain about make

[01:05:03.0000] <nox>
The current element being <html> in the case of fragment parsing sounds wrong. :(

[01:06:48.0000] <MikeSmith>
cvrebert: I guess but to begin with, the script is bash script, no at .bat

[01:29:28.0000] <annevk>
cvrebert: I guess I'm saying only use nightly builds when working on standards and browsers :-)

[01:30:05.0000] <annevk>
MikeSmith: sorry, got called away again, did you make some progress?

[01:30:51.0000] <cvrebert>
annevk: Nightly still acts equally weird in that case. Just like the other browsers. :-)

[01:30:59.0000] <annevk>
nox: I'm not sure

[01:31:07.0000] <annevk>
cvrebert: it doesn't here...

[01:31:12.0000] <nox>
annevk: About which part?

[01:31:22.0000] <annevk>
cvrebert: 43.0a1 (2015-09-02)

[01:31:29.0000] <annevk>
nox: about innerHTML

[01:31:34.0000] <nox>
annevk: I'm 99.44% sure I'm right about template contents not being used in this case.

[01:31:58.0000] <nox>
annevk: And given it specifically sets the stack of template insertion modes in the case of template fragment, I think this is a bug.

[01:32:19.0000] <nox>
annevk: Firefox and Safari put #t2 in the outer template contents.

[01:32:26.0000] <nox>
And there are WPT tests that check for that.

[01:32:35.0000] <annevk>
nox: HTML has one open bug about adjusted iirc

[01:32:38.0000] <nox>
/html/semantics/scripting-1/the-template-element/definitions/template-contents.html

[01:32:41.0000] <nox>
annevk: Oh, link?

[01:32:50.0000] <annevk>
nox: I can look...

[01:33:03.0000] <nox>
annevk: I plan to make a PR for HTML to make template use the adopting steps appropriately anyway.

[01:33:23.0000] <annevk>
nox: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27314

[01:33:33.0000] <annevk>
nox: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26783 is another bug on that algorithm though unrelated

[01:34:17.0000] <annevk>
nox: that sounds great. Please include a pointer to the tests and some documentation since I'm sure we'll need all that to review

[01:34:21.0000] <nox>
bzbarksy sounds right.

[01:34:25.0000] <annevk>
nox: none of us is very experienced in this part of the code

[01:34:31.0000] <annevk>
nox: that's not uncommon :-)

[01:34:45.0000] <MikeSmith>
annevk: making progress, yeah

[01:35:30.0000] <annevk>
https://github.com/whatwg/html/pull/26#issuecomment-137360727 should I ask this person to keep discourse respectful or just leave it?

[01:35:57.0000] <MikeSmith>
annevk: feel free to work on other stuff for the time being. I think at this point I understand what you and Domenic want and what we need, so I'll work on making it. And if I misunderstand anything, we just iterate.

[01:36:13.0000] <MikeSmith>
annevk: do not ask publicly

[01:36:15.0000] <annevk>
MikeSmith: that sounds great, thank you

[01:36:41.0000] <MikeSmith>
I think the first rule of dealing with trolls is not to give them any additional public attention

[01:36:45.0000] <annevk>
GitHub has no way to message another usage

[01:36:49.0000] <annevk>
s/usage/user/

[01:36:50.0000] <MikeSmith>
yeah

[01:37:06.0000] <MikeSmith>
so just delete the comment

[01:37:08.0000] <MikeSmith>
IMHO

[01:37:38.0000] <annevk>
Seems reasonable for this one

[01:37:48.0000] <MikeSmith>
github should have a way you can flag a comment as spam so that a github dev can deal with it

[01:37:53.0000] <MikeSmith>
yeah

[01:38:14.0000] <annevk>
I was tempted before to just remove the "Please reopen" statement since it wasn't constructive, but I decided not to since I figured it might create more flames

[01:38:16.0000] <nox>
Being fed up by a technical decision isn't trolling, IMO

[01:38:21.0000] <nox>
Happens to all of us.

[01:38:26.0000] <MikeSmith>
sure

[01:38:27.0000] <nox>
Isn't constructive, but not trolling.

[01:38:39.0000] <MikeSmith>
but *expressing* frustration like that is trolling

[01:38:49.0000] <nox>
Also, reporting people means getting them shadow-banned, sometimes, on GH.

[01:38:49.0000] <annevk>
nox: saying "I laugh at your statements" is trolling, imo

[01:39:01.0000] <nox>
annevk: It's being fed up, and thinking incompetence is involved.

[01:39:02.0000] <MikeSmith>
and it adds nothing constructive, so deleting it is no loss

[01:39:39.0000] <nox>
MikeSmith: I would redact it. Deleting sounds like you are scared.

[01:39:54.0000] <MikeSmith>
nox: IMHO, somebody adding comments like that deserves to be shadow-banned

[01:40:01.0000] <nox>
(In a fed up people mind that think Google, of all entities, is feeling pressure.)

[01:40:06.0000] <nox>
MikeSmith: What?!

[01:40:16.0000] <nox>
Shadow-banned is the most passive-aggressive douche move ever.

[01:40:31.0000] <MikeSmith>
wow

[01:40:50.0000] <MikeSmith>
I guess I don't even know what shadow-banning is then

[01:40:56.0000] <nox>
MikeSmith: You are banned,

[01:40:58.0000] <nox>
but everything works.

[01:41:04.0000] <nox>
You don't know you are banned.

[01:41:09.0000] <annevk>
cvrebert: ah, you're not using Nightly, developer edition is not recent enough it seems

[01:41:09.0000] <MikeSmith>
oh

[01:41:21.0000] <MikeSmith>
nox: yeah that's just dumb

[01:41:37.0000] <nox>
MikeSmith: It's fun though, your repositories are still available and whatnot,

[01:41:39.0000] <MikeSmith>
nox: anyway, maybe you can see what effect comments like that have

[01:41:41.0000] <nox>
but your profile says 404,

[01:41:43.0000] <nox>
so in a way,

[01:41:52.0000] <nox>
trolling on GH is the best way to get private repos for free.

[01:42:02.0000] <nox>
MikeSmith: Sure.

[01:42:05.0000] <MikeSmith>
that guy's comment has made the two of us argue with each other and waste time on it

[01:42:16.0000] <MikeSmith>
right now I just want to fixing the HTML spec build script

[01:42:23.0000] <nox>
MikeSmith: But I say stupid things when I am fed up by a spec sometimes. :) If that person has an history of doing this, sure.

[01:42:35.0000] <MikeSmith>
but instead this guy has sucked us into his little world of negativity

[01:42:41.0000] <MikeSmith>
yeah

[01:42:43.0000] <MikeSmith>
sure

[01:42:47.0000] <MikeSmith>
we all do it sometimes

[01:43:00.0000] <MikeSmith>
we need our friends to tell us to cut it out

[01:43:02.0000] <cvrebert>
annevk: but anyhow, it's a cross-browser quirk

[01:43:32.0000] <MikeSmith>
nox: anyway, I do understand what you're saying

[01:44:23.0000] <MikeSmith>
I'm just a little sensitive after 8 years of dealing with lots of dysfunctional communication and people in a really large WG

[01:44:32.0000] <nox>
Ah ah.

[01:45:22.0000] <annevk>
cvrebert: well was

[01:45:45.0000] <annevk>
cvrebert: Firefox is now correct, I'm sure other browsers would be okay with cleaning up their code too, since the new behavior would be simpler

[01:46:18.0000] <nox>
annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27314#c23

[01:47:34.0000] <cvrebert>
annevk: although this does beg the question why everyone had this same quirk in the first place

[01:48:34.0000] <annevk>
cvrebert: yeah, I wonder what bug changed the behavior in Firefox and what the actual patch was for that, but not curious enough to start digging

[01:48:59.0000] <mkwst>
annevk: Is there a term in Fetch for things that the browser requests outside the context of a page? We used to have an "internal" context for those requests... I guess an `initiator` and `destination` of ""?

[01:50:06.0000] <annevk>
mkwst: I guess it depends on whether it's exposed somehow or not

[01:50:32.0000] <annevk>
MikeSmith: is there a fix for the wattsi thing yet to use the local one when available?

[01:50:44.0000] <annevk>
MikeSmith: or should I look into that? kind of annoying to have that broken

[01:50:54.0000] <mkwst>
annevk: I'm looking at https://github.com/w3c/webappsec/issues/246, which concerns requests made to populate browser UI.

[01:50:57.0000] <MikeSmith>
annevk: will fix it right now and push it master

[01:51:02.0000] <MikeSmith>
gimme a couple minutes

[01:52:16.0000] <annevk>
mkwst: that seems like /favicon type of requests which do go through the service worker, no?

[01:52:22.0000] <annevk>
mkwst: are they really distinct from the page?

[01:53:01.0000] <mkwst>
They aren't revealed to the page until the user chooses to do so, and then only one of potentially several.

[01:53:31.0000] <mkwst>
That is, the browser constructs the chooser UI using SEKRIT INFORMATIONS, and then, if the user chooses to do so, reveals a portion of those secrets to the page.

[01:53:52.0000] <mkwst>
So, no, they aren't requests generated by the page, or that the page should know about.

[01:55:09.0000] <annevk>
But the page controls the URLs, no?

[01:55:24.0000] <annevk>
Sounds leaky...

[01:56:24.0000] <yoav>
mkwst: Trying to catch up on which requests you're talking about, but are such requests excluded from things like resource timing?

[01:56:27.0000] <mkwst>
No, the page doesn't control the URLs. Federations, for instance, will show up in the chooser even if you've never used them on the page.

[01:57:01.0000] <mkwst>
yoav: requests to populate the images in interfaces like https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection

[01:57:23.0000] <annevk>
Hmm

[01:57:30.0000] <mkwst>
annevk: Or the same interface in the context of chrome://settings/passwords/totallyAwesomeConfigurationPage

[01:58:24.0000] <annevk>
I guess as long as you set the skip service worker flag you should be okay

[01:58:49.0000] <annevk>
And then it doesn't really matter what you set for the rest, except for CSP and such, except since there's no client those won't work either I assume

[02:02:25.0000] <mkwst>
Right. I think that's the case.

[02:02:30.0000] <mkwst>
Cool, thanks.

[02:07:29.0000] <annevk>
mkwst: sorry for not finding all style nits in one go

[02:07:39.0000] <annevk>
(re csp state)

[02:08:42.0000] <mkwst>
annevk: no worries. the squashing/force-pushing is a bit annoying, though, as all the context and discussion is lost. i wonder if there's a way to simplify that workflow.

[02:09:09.0000] <MikeSmith>
mkwst: about the 'Content-Security-Policy' pragma directive PR, I will review also and add comments (if any) after I do

[02:09:55.0000] <MikeSmith>
annevk: if we can, please hold off on pushing that PR til I can make time to review (later tonight or tomorrow)

[02:10:07.0000] <MikeSmith>
the build script is going to take some time

[02:10:07.0000] <annevk>
MikeSmith: sure

[02:10:19.0000] <MikeSmith>
annevk: will push the wattsi fix right not

[02:10:20.0000] <MikeSmith>
*now

[02:10:39.0000] <annevk>
mkwst: we could do the rebase at the end?

[02:10:47.0000] <mkwst>
MikeSmith: No rush. Happy to wait for you.

[02:10:57.0000] <MikeSmith>
k

[02:11:00.0000] <annevk>
mkwst: first many commits, then squash and go

[02:11:12.0000] <Ms2ger>
Did we really add another http-equiv?

[02:11:19.0000] <mkwst>
annevk: Yeah. That's probably better. It slows things down marginally, as the reviewer can't just land it, but whatever.

[02:11:29.0000] <mkwst>
Ms2ger: Yes! Aren't you thrilled?! :)

[02:11:51.0000] <Ms2ger>
I'm sad

[02:11:57.0000] <annevk>
Ms2ger: there's referrer-policy too, though I guess that's <meta name=...>

[02:12:06.0000] <Ms2ger>
But I work on browsers, so I'm always sad

[02:12:10.0000] <mkwst>
Ms2ger: We added it ~4 years ago, if that makes it any better?

[02:12:15.0000] <Ms2ger>
No

[02:12:23.0000] <mkwst>
Didn't think so.

[02:13:58.0000] <MikeSmith>
annevk: pull now on master and test and it should work for you again

[02:14:43.0000] <MikeSmith>
fwiw I also agree with mkwst as far as "the squashing/force-pushing is a bit annoying, though, as all the context and discussion is lost"

[02:15:12.0000] <MikeSmith>
sometimes you want to preserve the context, sometimes it's not valuable and can just be squashd

[02:15:15.0000] <Ms2ger>
Only if you're silly enough to review on github :)

[02:15:23.0000] <MikeSmith>
heh

[02:15:24.0000] <nox>
Ms2ger!

[02:15:37.0000] <MikeSmith>
true that, Ms2ger

[02:15:40.0000] <nox>
Ms2ger: Would you mind checking what I mentioned earlier, to be sure about what I'm saying?

[02:15:55.0000] <Ms2ger>
About shadow-banning?

[02:16:32.0000] <nox>
No, lol.

[02:16:40.0000] <nox>
Ms2ger: About fragment parsing in template contexts.

[02:17:37.0000] <MikeSmith>
:) > "But I work on browsers, so I'm always sad"

[02:17:50.0000] <MikeSmith>
s/browsers/the Web platform/

[02:18:06.0000] <Ms2ger>
I'd rather not

[02:18:29.0000] <MikeSmith>
well I didn't mean your statement about what you work on

[02:18:29.0000] <nox>
MikeSmith: When sad, remember https://twitter.com/nokusu/status/634091274962894848.

[02:18:43.0000] <MikeSmith>
Ms2ger: I meant the part about having a reason to weep

[02:19:25.0000] <MikeSmith>
/me follows https://twitter.com/nokusu/status/634091274962894848 .. hopes it's not a goatse ....

[02:19:34.0000] <MikeSmith>
hahah

[02:19:42.0000] <annevk>
thanks MikeSmith, works

[02:19:46.0000] <MikeSmith>
super

[02:19:57.0000] <MikeSmith>
nox: triple-favorited

[02:20:46.0000] <Ms2ger>
*I'd rather not think about template parsing

[02:21:55.0000] <nox>
Ms2ger: :(

[02:23:35.0000] <MikeSmith>
damn this build script is way too network-bound

[02:25:01.0000] <Ms2ger>
cvrebert, moral of the story: don't expect jsbin to render the html you gave it

[02:25:54.0000] <cvrebert>
:-/

[02:26:49.0000] <MikeSmith>
annevk: I'm at the office and I need to leave soon to catch the train back to shinjuku, so will start back on build stuff in maybe 2.5 or 3 hours from now

[02:38:07.0000] <annevk>
MikeSmith: you probably also want to look at https://github.com/benschwarz/developers.whatwg.org/issues/104

[02:38:17.0000] <annevk>
MikeSmith: okay

[02:42:51.0000] <annevk>
Ms2ger: cvrebert: perhaps it only worked for me because I made some local changes and then ran it again? That sounds very unreliable

[02:43:23.0000] <annevk>
This reminds me of something JakeA did in jsbin and I couldn't reproduce elsewhere

[02:43:38.0000] <annevk>
Probably best to ask tests to be moved next time around

[02:46:51.0000] <annevk>
Krinkle_: seems you didn't actually have access to https://github.com/whatwg/sourcemap so I fixed that

[03:04:06.0000] <annevk>
MikeSmith: for some reason ./build.sh hangs for a long time on grep

[03:04:18.0000] <annevk>
MikeSmith: which is right at the start with the svn stuff

[03:06:36.0000] <annevk>
MikeSmith: so the reason .wattsi-output doesn't contain multipage/ is because the build.sh script moves that

[03:06:55.0000] <annevk>
MikeSmith: anyway, I guess I'll give up on this for a bit and work on something else

[03:11:26.0000] <MikeSmith>
annevk: I think that just hangs because that grep actually takes a very long time to run

[03:12:11.0000] <MikeSmith>
I think it's grepping through the entire svn log for all the Unicode locale data

[03:12:21.0000] <MikeSmith>
or something

[03:13:01.0000] <annevk>
o_O

[03:13:16.0000] <annevk>
Hmm, running svn up .cldr-data also takes a long time to run

[03:13:17.0000] <MikeSmith>
Anyway if you do "git checkout sideshowbarker/rework" and then run build.sh -v

[03:13:23.0000] <MikeSmith>
yeah

[03:13:42.0000] <annevk>
I was thinking maybe we should just run that everytime and store the revision someplace

[03:13:45.0000] <MikeSmith>
I added that -v switch because of this

[03:13:54.0000] <MikeSmith>
yeah maybe

[03:14:40.0000] <annevk>
Might be better to have a switch to not do cldr-data

[03:14:49.0000] <annevk>
Or opt into it...

[03:14:58.0000] <zcorpan>
doing the redirect in htaccess appears to be a bit hairy, it's probably better to do it in python (for web-apps-tracker)

[03:15:10.0000] <annevk>
zcorpan: why?

[03:15:25.0000] <annevk>
zcorpan: oh the query string one?

[03:15:28.0000] <zcorpan>
annevk: yeah

[03:15:41.0000] <zcorpan>
plain Redirect doesn't do query strings

[03:16:54.0000] <zcorpan>
there's RewriteMap that could work but it can't be declared in htaccess

[03:17:36.0000] <annevk>
zcorpan: http://serverfault.com/questions/500961/redirectmatch-and-query-string

[03:18:03.0000] <annevk>
not sure about the merits of mod_rewrite vs Python though

[03:18:14.0000] <annevk>
the bit in Python we have for this today is quite simple too

[03:21:03.0000] <zcorpan>
htaccess might cause slowness for the rest of the site, from what i understand

[03:25:16.0000] <ato>
If in a specification I want to say that something can be one of either three things (a set), what’s the normal way to do this?

[03:27:50.0000] <MikeSmith>
enumerated

[03:29:35.0000] <MikeSmith>
ato: see the way the HTML spec words it

[03:29:54.0000] <MikeSmith>
search for "enumerated"

[03:31:07.0000] <ato>
MikeSmith: Thanks

[03:33:52.0000] <MikeSmith>
annevk: So yeah I reckon that the first thing I'll do when I get home is, I'll add a -u switch for optting in to asking it to do an update; e.g., the svn up thing it wants to run, and all that whatever the hell stuff it keeps re-downloading each time

[03:34:29.0000] <MikeSmith>
and switch the default to being, don't do that

[03:34:51.0000] <MikeSmith>
don't do that unless we ask you to

[03:36:04.0000] <MikeSmith>
that with hell lower our blood pressure and choices focus on the actual build improvements we want to make

[03:36:18.0000] <MikeSmith>
without the lag and the noise

[03:38:18.0000] <MikeSmith>
ato: The cases that use that "enumerated" language may not be what you had in mind or need

[03:38:49.0000] <ato>
MikeSmith: It might be a bit heavy in my case, yes.  But I can draw some inspiration from it (-:

[03:39:01.0000] <MikeSmith>
k

[03:41:05.0000] <hsivonen>
SimonSapin: does there exist an Encoding Standard implementation for Rust?

[03:46:29.0000] <nox>
hsivonen: Yes, rust-encoding.

[03:48:20.0000] <smaug____>
/me wonders whether to attend tpax

[03:48:23.0000] <smaug____>
tpac

[03:48:44.0000] <hsivonen>
is https://github.com/lifthrasiir/rust-encoding the canonical repo?

[03:49:49.0000] <nox>
hsivonen: AFAIK yes.

[03:50:07.0000] <nox>
Why, btw?

[03:51:09.0000] <annevk>
ato: you can say "one of A, B, and C"

[03:51:15.0000] <annevk>
ato: that's what I usually use

[03:52:01.0000] <annevk>
MikeSmith: that sounds amazing

[03:52:44.0000] <annevk>
hsivonen: is the best way to get you to reply on GitHub to send you a note on IRC?

[03:53:07.0000] <annevk>
hsivonen: https://github.com/whatwg/encoding/issues/9 for context

[03:57:24.0000] <zcorpan>
smaug____: i plan to attend tpac, fwiw

[03:57:43.0000] <annevk>
smaug____: it would be fun to hang out

[03:58:00.0000] <annevk>
smaug____: which incidentally is the main reason I'm going

[03:58:14.0000] <jgraham>
AFAICT it's the only reason I'm going

[03:58:23.0000] <smaug____>
:)

[03:58:38.0000] <smaug____>
visiting Japan would be a good reason to go

[04:02:37.0000] <MikeSmith>
I don't know if y'all heard yet but it's unlikely I'll be at TPAC this year

[04:03:00.0000] <MikeSmith>
because my wife and I have a baby on the way

[04:03:12.0000] <MikeSmith>
due Oct 14

[04:03:56.0000] <annevk>
So it seems the patch from jungkees didn't do line wrapping Domenic

[04:04:24.0000] <annevk>
We could really use some pull request bots that check a couple of things

[04:05:06.0000] <annevk>
MikeSmith: public congrats! :-)

[04:05:15.0000] <smaug____>
congrats!

[04:05:23.0000] <jgraham>
MikeSmith: Good news for you, but now I am slightly more wondering why I'm going to Japan :)

[04:09:45.0000] <MikeSmith>
heh

[04:10:19.0000] <MikeSmith>
Thanks all for the congrats

[04:11:49.0000] <Ms2ger>
Poor kid ;)

[04:13:22.0000] <MikeSmith>
with all y'all planning to be there, I'm disappointed that I won't be. But you'll have plenty of good times without me

[04:16:41.0000] <MikeSmith>
maybe you can even get gsnedders to attend this year

[04:16:54.0000] <MikeSmith>
that would be truly awesome

[04:19:32.0000] <zcorpan>
MikeSmith: congrats!

[04:21:19.0000] <mkwst>
MikeSmith: Yay! Babies are awesome. Congratulations!

[04:35:11.0000] <SimonSapin>
hsivonen: yes, as nox said

[04:46:07.0000] <gsnedders>
MikeSmith: I'm planning to be there, bah

[04:47:34.0000] <gsnedders>
Not quite bought flights yet, though

[04:47:38.0000] <gsnedders>
MikeSmith: anyhow, congrats!

[04:51:40.0000] <MikeSmith>
thanks

[04:53:57.0000] <hsivonen>
nox: The converters in Gecko are generally the sort of code you don't want to modify and we should modify them somewhat

[04:54:04.0000] <hsivonen>
annevk: yes

[04:54:51.0000] <hsivonen>
nox: looks like the Rust impl. doesn't pack the tables as space-efficiently in the binary as I would

[04:55:03.0000] <hsivonen>
(and am doing with my Big5 rewrite for Gecko)

[04:55:08.0000] <nox>
hsivonen: rust-encoding is quite naive on all fronts, IMO.

[04:55:52.0000] <hsivonen>
nox: anyway, I'll take a more careful look to see how crazy it would be to propose that we moved Gecko over to Rust-based converters

[05:01:06.0000] <nox>
hsivonen: Cool.

[05:02:17.0000] <gsnedders>
/me has some vague plan to start implementing more crazy SIMD optimizations for rust-encoding

[05:04:02.0000] <hsivonen>
for example, the Big5 data can be made space-efficient like this: https://hg.mozilla.org/projects/htmlparser/file/0d906fb1ab90/src/nu/validator/encoding/Big5Data.java while still keeping decode fast

[05:04:33.0000] <hsivonen>
(don't look at the other code in that package. e.g. the single-byte stuff is very naive)

[05:13:53.0000] <MikeSmith>
/me thanks zcorpan and mkwst as well

[05:21:02.0000] <annevk>
hsivonen: Python to Java to C++?

[05:21:27.0000] <annevk>
hsivonen: are you upping your code-to-code conversion game?

[05:25:20.0000] <gsnedders>
annevk: you forgot about emscriptening the C++ to JS.

[05:25:43.0000] <annevk>
gsnedders: and then back to assembly (web)

[05:26:38.0000] <annevk>
Might need some help from Xzibit here

[05:35:00.0000] <roc>
hsivonen: moving to Rust-based converters would be great! If anything gets in the way, bring it up in dev-platform

[05:38:15.0000] <Ms2ger>
Reading the text, does this test pass or fail? http://test.csswg.org/harness/test/css21_dev/single/selectors-001/format/html4/

[05:39:18.0000] <annevk>
pass

[05:39:53.0000] <annevk>
Ms2ger: though I see what you mean

[05:40:01.0000] <Ms2ger>
But the text is white! :)

[05:42:40.0000] <gsnedders>
fails, definitely fails

[05:43:14.0000] <nox>
hsivonen: Since you are here,

[05:43:28.0000] <nox>
hsivonen: do you know how Gecko works when parsing template fragments?

[05:43:51.0000] <nox>
I see you commented in the past on https://www.w3.org/Bugs/Public/show_bug.cgi?id=27314, which I stumbled upon while implementing templates in Servo.

[05:51:18.0000] <MikeSmith>
annevk: so the code at https://github.com/whatwg/html-build/blob/master/.pre-process-main.pl#L50 causes the build to (re)download example HTML+JS+CSS files from, e.g., https://whatwg.org/demos/workers/multicore/

[05:51:40.0000] <MikeSmith>
see the comment in the code there

[05:51:47.0000] <MikeSmith>
        # TODO: maybe move these to the HTML source repo, and upload them to whatwg.org from there?

[05:51:50.0000] <MikeSmith>
        # Or maybe better, redirect from these URLs to new html.spec.whatwg.org URLs

[05:52:03.0000] <MikeSmith>
so yeah, later, let's do that

[05:52:04.0000] <Domenic>
MikeSmith: https://github.com/whatwg/html/issues/30

[05:52:16.0000] <MikeSmith>
hey Domenic is awake

[05:52:18.0000] <Domenic>
It's getting to be a pretty large time sink in the build process

[05:52:28.0000] <Domenic>
\o/

[05:52:38.0000] <MikeSmith>
man you are always way ahead of me

[05:53:05.0000] <annevk>
You know what, we should commit those downloaded resources to whatwg/html/demos/

[05:53:13.0000] <annevk>
And then ask Hixie to put up redirects

[05:53:35.0000] <MikeSmith>
"We should move the demos into this repo, and have the build script inline them from source plus copy them to the output directory." yes

[05:53:49.0000] <MikeSmith>
annevk: yeah

[05:54:23.0000] <annevk>
Hixie wanted to set up some kind of demos.whatwg.org thing but I don't think that's needed necessarily, each specification can take care of their own demos

[05:54:50.0000] <Ms2ger>
gsnedders, can I ask you for test reviews already? :)

[05:55:32.0000] <MikeSmith>
well for now I guess I can have a build script pass an option to that perl script to tell it not to download that stuff

[05:55:37.0000] <MikeSmith>
ok?

[05:55:55.0000] <annevk>
MikeSmith: not downloading them would create a bogus index infortunately

[05:56:00.0000] <annevk>
MikeSmith: since the demos are inlined

[05:56:04.0000] <MikeSmith>
ah OK

[05:56:07.0000] <MikeSmith>
I see now

[05:56:09.0000] <MikeSmith>
yeah

[05:56:23.0000] <annevk>
but they are static non-changing files afaik

[05:56:25.0000] <Domenic>
annevk: doesn't committing https://github.com/whatwg/html/commit/a262f1d23cb8990a4735436215a01f0f4892f1a1 directly without the corresponding html-build changes break the multipage version?

[05:56:41.0000] <Domenic>
annevk: since .multipage-404 doesn't exist anymore?

[05:56:46.0000] <MikeSmith>
well we can have the build script download them *once* right

[05:56:56.0000] <annevk>
Domenic: therefore it's on a branch

[05:57:15.0000] <annevk>
Domenic: just wanted to share progress with MikeSmith

[05:57:17.0000] <Domenic>
annevk: tiiiiiny little branch indicator, got it

[05:57:48.0000] <annevk>
(it's also out-of-date at the moment, since I changed the .htaccess to fix some other things)

[06:00:23.0000] <annevk>
MikeSmith: yeah, changing those lines to also store the files somewhere seems sensible

[06:00:43.0000] <annevk>
MikeSmith: and then if you run this again, update flag is not set, and the files are stored, you keep whatever you got last time

[06:01:02.0000] <annevk>
MikeSmith: still risks some staleness, but only locally since I guess the server will always set the update flag

[06:01:08.0000] <Domenic>
We should probably just bug Hixie harder to give us the demos and do it all in one step

[06:01:33.0000] <annevk>
MikeSmith: alternatively, once you downloaded them and stored them somewhere, just check them into the html repo and then change the script to open files there...

[06:02:00.0000] <annevk>
ah I guess what will fail then is subresources, which are not downloaded

[06:02:04.0000] <annevk>
so yeah, need to bug Hixie

[06:03:14.0000] <MikeSmith>
/me misreads label in github issue tracker as "spec trolling"

[06:03:48.0000] <MikeSmith>
> "still risks some staleness, but only locally since I guess the server will always set the update flag" yes

[06:04:19.0000] <MikeSmith>
yeah we need Hixie for the longer-term fix

[06:09:58.0000] <Domenic>
Anyone want to help the parse5 maintainer understand the ruby parsing story? https://github.com/inikulin/parse5/commit/c61acf300904a85a12835ae95e13bae08d288225 I don't know it in real detail myself

[06:16:05.0000] <gsnedders>
Ms2ger: still trying to do finance bullshit, so no

[06:16:42.0000] <gsnedders>
Domenic: tl;dr: Hixie said no so it's not in the WHATWG spec, it's in the W3C spec and everyone implements it.

[06:18:21.0000] <nox>
gsnedders: I see.

[06:18:27.0000] <nox>
gsnedders: Why did Hixie say no?

[06:18:58.0000] <nox>
html5lib-tests follows W3C too.

[06:19:24.0000] <gsnedders>
nox: html5lib-tests follows what everyone is actually implementing

[06:19:38.0000] <Ms2ger>
Because the additional complexity isn't necessary

[06:20:15.0000] <gsnedders>
nox: which is WHATWG plus the Ruby stuff from the W3C spec.

[06:21:37.0000] <gsnedders>
Domenic: I've commented, FWIW

[06:23:22.0000] <nox>
Ms2ger: But it's already implemented by UAs. Why remove that?

[06:23:30.0000] <gsnedders>
nox: it wasn't removed

[06:23:37.0000] <gsnedders>
nox: it was added to UAs after Hixie said no

[06:23:52.0000] <nox>
Oh.

[06:24:15.0000] <nox>
So, who is wrong?

[06:24:23.0000] <Ms2ger>
Everyone

[06:24:24.0000] <gsnedders>
The WHATWG spec, because it is a lie.

[06:24:43.0000] <jgraham>
Ms2ger: You're confusing "wrong" and "dead"

[06:24:45.0000] <nox>
Ms2ger: Ah ah.

[06:24:51.0000] <nox>
gsnedders: Ok.

[06:25:11.0000] <nox>
gsnedders: It lies for fragment parsing too, but no one described what Gecko actually does. :(

[06:25:30.0000] <gsnedders>
nox: is there interop there?

[06:25:37.0000] <gsnedders>
nox: like, where is it wrong?

[06:25:41.0000] <nox>
gsnedders: Yes there is.

[06:25:49.0000] <gsnedders>
nox: do we have tests for where it is wrong? what do the tests expect?

[06:25:59.0000] <nox>
gsnedders: From my understanding, for example parsing innerHTML of a template,

[06:26:06.0000] <nox>
gsnedders: the children should end up in template contents,

[06:26:10.0000] <nox>
gsnedders: spec doesn't do that.

[06:26:20.0000] <gsnedders>
nox: oh, so it's only the template case that is wrong?

[06:26:23.0000] <nox>
gsnedders: Or spec is so confusing I don't see which path it follows for this.

[06:26:34.0000] <nox>
gsnedders: Not sure. There are other confusing details mentioned in ticket.

[06:26:45.0000] <Joseph__Silber>
TabAtkins, is it possible in flexbox to have equal-height elements *across multiple lines*? So that if something in one row expands, all items in all other rows would expand as well.

[06:26:50.0000] <nox>
gsnedders: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27314#c23

[06:27:16.0000] <nox>
gsnedders: I can imagine it making weird things for foreign content fragments too.

[06:27:33.0000] <nox>
(Since current node is <html>, not a foreign node.)

[06:27:39.0000] <gsnedders>
Joseph__Silber: no, AIUI

[06:27:45.0000] <gsnedders>
Joseph__Silber: (I could be wrong)

[06:28:11.0000] <Joseph__Silber>
Thought so too

[06:28:12.0000] <gsnedders>
nox: is the foreign content case not handled by the tree construction dispatcher

[06:28:19.0000] <Joseph__Silber>
Wanted to hear from the man himself :)

[06:28:51.0000] <nox>
gsnedders: Mmh, no but I think it makes use of the adjusted current node.

[06:29:22.0000] <gsnedders>
nox: it seems to be given it uses the adjusted current node, which is context if we're fragment case and the stack of open elements contains only html

[06:29:33.0000] <gsnedders>
nox: so I think the foreign content case is right per spec?

[06:29:37.0000] <nox>
gsnedders: I tried to unconditionally use it for step 1 of https://html.spec.whatwg.org/multipage/syntax.html#appropriate-place-for-inserting-a-node but it made other unrelated tests fail.

[06:30:27.0000] <gsnedders>
hmm, will look into this later

[06:30:31.0000] <nox>
gsnedders: Thanks.

[06:30:40.0000] <nox>
gsnedders: Firefox and WebKit both do the correct thing btw.

[06:36:55.0000] <gsnedders>
FWIW, if anyone wants to look over https://critic.hoppipolla.co.uk/r/5781

[06:37:00.0000] <gsnedders>
please feel free to do so

[06:41:40.0000] <jgraham>
gsnedders: I would be more inclinded to do so if you would address your own comments

[06:42:08.0000] <gsnedders>
pff

[06:42:32.0000] <gsnedders>
some of them I'd like opinions on, FWIW

[06:43:58.0000] <jgraham>
If the test doesn't test what the spec says but what chrome would like it to say then I agree we shouldn't take those tests

[06:44:43.0000] <JakeA>
TabAtkins: there's a proposal for a property to give an element a fixed aspect ratio right? Which spec is it in?

[06:45:23.0000] <TabAtkins>
None. There's a broken proposal for this on my blog, but it's no good for subtle reasons.

[06:45:50.0000] <TabAtkins>
Joseph__Silber: No, but Grid can do that.

[06:45:52.0000] <gsnedders>
jgraham: but like, dropping SVG fonts doesn't mean you don't need to normalise SVG font attributes, right?

[06:46:12.0000] <Joseph__Silber>
Yeah I know. Just Flexbox currently has way broader support.

[06:46:13.0000] <Joseph__Silber>
Thanks.

[06:47:16.0000] <Joseph__Silber>
JakeA, guess you're stuck with absolute positioning in a padded container...

[06:47:22.0000] <jgraham>
gsnedders: Right

[06:47:42.0000] <jgraham>
That doesn't make sense unless everyone has agreed on it

[06:48:34.0000] <JakeA>
Joseph__Silber: yeah, that's what I'm using. Just seeing if there's something less hacky on the way

[06:52:18.0000] <Domenic>
gsnedders: thanks! The parse5 guy is great and so I am happy when we can help him (like you also did by commenting on the test update issue)

[06:53:42.0000] <Domenic>
/me watches html5lib-tests on GitHub

[06:56:23.0000] <gsnedders>
Domenic: feel free to ping me on anything you see about html5lib-tests, FWIW

[06:56:34.0000] <gsnedders>
Domenic: regardless of whether or not it's really justified :)

[06:56:41.0000] <Domenic>
:)

[07:11:48.0000] <wanderview>
mkwst: I guess I could just try to make a spec-directory page instead of whining about it till someone makes it for me

[07:14:03.0000] <mkwst>
wanderview: Yeah. Each WG should have one anyway.

[07:14:23.0000] <wanderview>
mkwst: I really want a master list... including a section for speculative stuff like navigator-connect, etc

[07:14:58.0000] <wanderview>
I have a hard time understanding the WG structure, to be honest

[07:15:04.0000] <mkwst>
Sure. It would be lovely to see what's being worked on before it's done and too late to argue about it.

[07:15:28.0000] <mkwst>
That's because there are only two that matter, and a bazillion others. ;P

[07:15:54.0000] <wanderview>
mkwst: what are the two that matter?

[07:16:25.0000] <wanderview>
anyway, sorry to hijack your twitter poll

[07:16:35.0000] <mkwst>
WebApps and WebAppSec.

[07:16:41.0000] <TabAtkins>
Oooh burn

[07:16:59.0000] <TabAtkins>
(The correct two are, of course, CSSWG and Houdini.)

[07:17:49.0000] <mkwst>
Ok, ok. Maybe marginally more than two.

[07:17:55.0000] <wanderview>
is whatwg considered a WG?

[07:18:10.0000] <TabAtkins>
It's right there in the name.

[07:18:15.0000] <mkwst>
(I forgot about CSS, which says something about my priorities. :) )

[07:18:38.0000] <jgraham>
This is like the Spanish inquisition

[07:18:50.0000] <Domenic>
It is not a W3C working group, however.

[07:18:51.0000] <gsnedders>
what about the WHATTF?

[07:19:30.0000] <TabAtkins>
That's not a WG, obvs.

[07:19:39.0000] <gsnedders>
I thought Houdini was a TF?

[07:20:22.0000] <wanderview>
I hope there is a web bureaucracy for newbies session at TPAC

[07:20:23.0000] <jgraham>
Also, Browser Tools & Testing is irrelevant to you, but is at least standardising a technology that all* browsers are implementing (*well except Apple ofc)

[07:21:30.0000] <mkwst>
Point is, lots of crazy in WGs.

[07:22:07.0000] <wanderview>
JakeA: do we know what day service workers is happening at tpac yet?

[07:22:52.0000] <jgraham>
You can probably ignore the Multimodal Interaction WG though :)

[07:22:54.0000] <JakeA>
wanderview: Monday or Tuesday

[07:23:11.0000] <wanderview>
JakeA: excellent, thanks

[07:23:29.0000] <wanderview>
/me will be gone after Thursday noon.

[07:24:10.0000] <JakeA>
yeah, took that into account

[07:24:31.0000] <wanderview>
thanks... saves me trouble at home for missing halloween

[07:24:45.0000] <wanderview>
although I may not be awake for it

[07:26:13.0000] <jgraham>
I find it strange every year that haloween is such a big deal in the US

[07:26:22.0000] <wanderview>
JakeA: I wonder when we should start talking about agenda... would be nice to maybe dig into fall-through or foreign-fetch more

[07:26:43.0000] <wanderview>
jgraham: I think its a bigger deal when your kids are still young...

[07:28:07.0000] <jgraham>
Yeah, makes sense. It's just unusual for there to be a thing that happens in both the US and UK but with totally different levels of importance in the two locations.

[07:28:30.0000] <gsnedders>
jgraham: I find it strange every year that someone trying to blow up Parliament in 1605 is such a big deal in the UK.

[07:29:08.0000] <jgraham>
gsnedders: Not such a big deal that I would change my travel plans to make sure I was back to celebrate it!

[07:29:27.0000] <jgraham>
gsnedders: Also as a Scottish person, you are supposed to be all in favour of blowing up parliment

[07:29:40.0000] <JakeA>
wanderview: agreed. I'd also like to figure out a replacement for fetchEvent.client

[07:29:58.0000] <wanderview>
JakeA: I thought we agreed on that one... but maybe it was just an agreement for "something else"

[07:30:56.0000] <JakeA>
wanderview: I think we agreed that sync was bad for a full client, but didn't decide if it should be clientID, or an async getter

[07:31:25.0000] <gsnedders>
jgraham: What? How do you know I'm part of the 45?

[07:33:00.0000] <wanderview>
jgraham: what happens for halloween in the UK?

[07:33:51.0000] <Domenic>
I am going to be in Japan during TPAC time for vacation but not attending TPAC.

[07:34:18.0000] <gsnedders>
wanderview: relatively little; there's a small amount of "trick or treating" compared with the US, AIUI, and that's about it

[07:34:31.0000] <gsnedders>
wanderview: typically going around known neighbours nearby

[07:34:37.0000] <jgraham>
wanderview: Pretyt much nothing

[07:34:47.0000] <gsnedders>
(tbf, maybe my viewpoint is bias by Scotland here?)

[07:34:53.0000] <jgraham>
But enough for it to be a thing

[07:35:19.0000] <gsnedders>
According to Wikipedia, guising is in origin Irish/Scottish

[07:35:23.0000] <jgraham>
I mean you can buy stuff for it and some people make lanterns and so on, but I can't imagine it ever being a big deal to miss it

[07:35:39.0000] <TabAtkins>
Domenic: That's interesting timing.

[07:35:40.0000] <gsnedders>
so maybe I don't know how little goes on in England and Wales?

[07:36:15.0000] <wanderview>
jgraham: I wouldn't care about it except my daughter enjoys trick-or-treating and it will be the first year my son dresses up

[07:36:28.0000] <wanderview>
mostly its just kids trick-or-treating in nearby neighbhorhoods

[07:36:45.0000] <wanderview>
my one neighbor goes all out with decorations, lights, and music... but most people don't do much

[07:37:01.0000] <gsnedders>
also traditionally here it's not so much trick *or* treating

[07:37:03.0000] <jgraham>
I usually hear at least one or two people complaining about TPAC/Halloween, so it's not just you

[07:37:07.0000] <gsnedders>
you're only meant to get the treat if you do the trick

[07:37:17.0000] <jgraham>
gsnedders: Huh?

[07:37:18.0000] <wanderview>
gsnedders: really?

[07:37:31.0000] <gsnedders>
jgraham: at least in my experience in Scotland, that's still relatively true

[07:37:32.0000] <wanderview>
I always thought it was a thread... give me a treat or I will egg your house

[07:37:32.0000] <jgraham>
gsnedders: Also are you sure that isn't just Glasgow

[07:37:40.0000] <wanderview>
^thread^threat

[07:37:41.0000] <gsnedders>
jgraham: not just Glasgow

[07:37:54.0000] <jgraham>
Like "I set your car on fire. Now give me sweets if you don't want tyour house to burn"

[07:38:08.0000] <wanderview>
I'll try that approach this year... "no candy unless you do a trick for me... do a hand stand!"

[07:38:12.0000] <gsnedders>
https://en.wikipedia.org/wiki/Trick-or-treating#Guising still seems relatively true in my experience

[07:38:58.0000] <gsnedders>
there's more sweets-for-nothing than there were when I was a child, AFAICT, though

[07:39:03.0000] <gsnedders>
and that's not exactly that long of a period

[08:03:25.0000] <JakeA>
zcorpan: thanks for the corrections btw. Appreciated

[08:03:53.0000] <zcorpan>
JakeA: np. i liked the svg :-)

[08:04:01.0000] <smaug____>
mounir: dglazkov or other blink folks, who maintains DeviceOrientation stuff in blink?

[08:04:07.0000] <zcorpan>
still need better svg authoring tools huh

[08:04:24.0000] <mounir>
smaug____: timvolodine⊙co

[08:04:36.0000] <smaug____>
thanks

[08:04:43.0000] <mounir>
smaug____: np :)

[08:04:46.0000] <JakeA>
I used Illustrator for the first time and I won't be using it again. Back to Inkscape.

[08:04:53.0000] <smaug____>
mounir: is he ever on IRC?

[08:05:27.0000] <JakeA>
Feels like there's an open goal for a good SVG editor though. Inkscape is pretty bad but it's the only one that's an SVG editor, rather than just exports-to-svg

[08:05:52.0000] <mounir>
smaug____: I wish IRC was used as much at Google than at Mozilla ;)

[08:11:44.0000] <annevk>
So along with Fetch integration / Ruby / security stuff?, it seems that Shadow DOM integration is also high priority for HTML

[08:12:37.0000] <annevk>
If anyone has anything else that's particularly important I'd love to know

[08:21:24.0000] <Domenic>
annevk: I'd say getting the ruby parsing changes integrated

[08:21:40.0000] <annevk>
Domenic: yeah that's on the list

[08:21:53.0000] <nox>
Fixing template fragments. :P

[08:22:16.0000] <annevk>
Domenic: should we fix the parser and not worry about conformance?

[08:23:03.0000] <Domenic>
annevk: hmm maybe, that might merit further discussion. I don't have strong conformance opinions in general... maybe MikeSmith can help given his validator experience.

[08:23:44.0000] <annevk>
I've been slowly figuring out what's needed for Fetch since it hurts the service worker work

[08:23:54.0000] <annevk>
Ironically appcache makes Fetch integration harder...

[08:24:51.0000] <annevk>
nox: hmm yeah

[08:43:01.0000] <nox>
annevk: Cool.

[08:44:22.0000] <nox>
annevk: I suspect 26783 isn't unrelated.

[08:44:26.0000] <nox>
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=26783)

[08:45:42.0000] <nox>
They reach the same conclusion of getting rid of "adjusted current node".

[08:48:23.0000] <wanderview>
mkwst: annevk: btw, from your conversation yesterday... gecko does implement .formData() on Request

[08:48:44.0000] <mkwst>
wanderview: Yeah, no idea why Chrome doesn't.

[08:48:56.0000] <wanderview>
mkwst: I assume it didn't make the cut for MVP

[08:51:46.0000] <Krinkle>
Hm.. is requestIdleCallback supposed to be guaranteed? E.g. if the user navigates away or refreshes, will it run before unload? setTimeout does not, for example.

[08:52:09.0000] <Krinkle>
but microtasks in general I imagine would get run like setImmediate and already scheduled event handlers

[08:53:16.0000] <Krinkle>
igrigorik: ^

[08:58:24.0000] <ccardona-work>
Good morning/afternoon/evening WHATWG crew o/

[08:59:27.0000] <nox>
Why should "<a><tr>" in a tbody fragment be parsed as "<a></a><tr></tr>"?

[09:00:09.0000] <Krinkle>
<a> is not a valid child of <tbody>

[09:00:13.0000] <Krinkle>
(I think(

[09:00:20.0000] <nox>
Krinkle: Hence my question. :)

[09:00:34.0000] <nox>
It's in html5lib-tests.

[09:01:13.0000] <Krinkle>
well, it can't remove the element. It has to go somewhere. Depending on how widely scoped the parse instruction is, it'll hoist it away as far as possible

[09:01:21.0000] <Krinkle>
parsing the entire table will make it go before <table> I think

[09:01:39.0000] <Krinkle>
unless there is an exception for <a> specifically.

[09:01:44.0000] <nox>
https://github.com/html5lib/html5lib-tests/blob/master/tree-construction/tests_innerHTML_1.dat#L483-L491

[09:01:49.0000] <jgraham>
nox: <table><tbody><a><tr> -> <a></a><table><tbody><tr>

[09:01:59.0000] <nox>
jgraham: I said in a fragment.

[09:02:05.0000] <jgraham>
Oh

[09:02:13.0000] <nox>
jgraham: tbody.innerHtml = '<a><tr>'

[09:02:48.0000] <Krinkle>
nox: what would you expect instead? <a><tr></tr></a>?

[09:02:50.0000] <ccardona-work>
This is w/out question the coolest room on freenode and one of the most valuable places that I know of online. Nice work everyone. 👍🏼

[09:02:58.0000] <nox>
Krinkle: No idea.

[09:03:23.0000] <jgraham>
Well it somewhat falls out of the other behaviour

[09:03:25.0000] <Krinkle>
nox: That test data is abstracted, I assume those pipes in the bottom portion refer to entire elements as siblings?

[09:03:35.0000] <nox>
Krinkle: Yes.

[09:03:42.0000] <nox>
Krinkle: It indents children.

[09:03:46.0000] <Krinkle>
Right

[09:03:47.0000] <jgraham>
<tr> closes <a>, but innerHTML obviously can't foster parent

[09:04:07.0000] <Krinkle>
Ah, that's it!

[09:04:26.0000] <nox>
Ok.

[09:04:59.0000] <jgraham>
I mean, if you start asking "why" about the html parser you'll quickly go mad

[09:05:12.0000] <nox>
jgraham: Trying to fix the spec wrt template fragments.

[09:05:15.0000] <nox>
So, lots of "why".

[09:06:06.0000] <jgraham>
Just picking a behaviour that makes sense seems sufficient, not trying to understand all teh historial legacy

[09:08:28.0000] <nox>
I wonder if I should just add a rule in "in template".

[09:08:46.0000] <nox>
Ah no, that wouldn't work.

[09:10:07.0000] <nox>
I'll just wait for someone to fix it I guess. :P

[09:28:35.0000] <annevk>
nox: ooh, you're going to supply a fix? Excellent

[09:28:53.0000] <nox>
annevk: Tried. Kinda failed. No idea where to fix this.

[09:28:58.0000] <annevk>
wanderview: ta

[09:29:44.0000] <annevk>
nox: ah okay, not sure what the priority is but I do plan on getting to the parser in due course

[09:47:18.0000] <nox>
annevk: Thanks.

[10:00:55.0000] <annevk>
heycam|away: roc: https://github.com/whatwg/html/issues/96

[10:01:02.0000] <annevk>
heycam|away: roc: seems reasonable...

[10:20:14.0000] <annevk>
nox: so I think the good news is that I think you did find a bug, the bad news is that I'm not sure how to fix it either

[10:20:32.0000] <nox>
annevk: Heh.

[10:21:12.0000] <nox>
annevk: Hence why I asked about whatever Gecko does, as bzbarsky implies it does something better.

[10:22:33.0000] <annevk>
nox: however, how does this work in the non-fragment case?

[10:22:42.0000] <nox>
annevk: What do you mean?

[10:23:01.0000] <nox>
annevk: In the non-fragment case, the template element is the current element, so the appropriate place for insertion is properly computed.

[10:23:34.0000] <nox>
And in the foster parenting case, it's in the stack of open elements anyway.

[10:23:40.0000] <annevk>
Actually, why does “If the adjusted insertion location is inside a template element, let it instead be inside the template element's template contents, after its last child (if any).” not work?

[10:24:07.0000] <nox>
Because the template isn't in the stack of open elements, it's the context element.

[10:24:09.0000] <annevk>
That seems to do the trick both for fragment and non-fragment

[10:24:12.0000] <nox>
And that's the foster parenting case.

[10:24:21.0000] <nox>
Oh right, adjusted insertion location.

[10:24:57.0000] <annevk>
nox: well, the fragment parser does put <template> on the stack I think

[10:24:58.0000] <annevk>
nox: see "Create a start tag token whose name is the local name of context and whose attributes are the attributes of context."

[10:25:26.0000] <nox>
annevk: "Let this start tag token be the start tag token of the context node, e.g. for the purposes of determining if it is an HTML integration point."

[10:25:31.0000] <nox>
Never it is put on the stack.

[10:25:55.0000] <nox>
The only element on the stack is root. "Let root be a new html element with no attributes."

[10:26:22.0000] <nox>
annevk: Step 1 of "appropriate place for inserting a node" sets target to current node. Current node is root.

[10:26:49.0000] <annevk>
Yeah okay

[10:26:52.0000] <annevk>
Hmm

[10:26:56.0000] <nox>
annevk: And even in the case of foster parenting,

[10:27:01.0000] <nox>
there is no template on the stack.

[10:27:32.0000] <nox>
Oh sorry, step 3.

[10:27:58.0000] <nox>
Wait no, that doesn't get run either, because "If there is no last table, then let adjusted insertion location be inside the first element in the stack of open elements (the html element), after its last child (if any), and abort these substeps. (fragment case)"

[10:28:14.0000] <nox>
In all cases, the element ends up in the html element, not the template contents.

[10:30:37.0000] <annevk>
So I was thinking, even if they end up in the template contents, the child nodes of root get returned in the end...

[10:31:42.0000] <annevk>
But https://w3c.github.io/DOM-Parsing/#widl-Element-innerHTML doesn't deal with this either

[10:35:19.0000] <annevk>
Domenic: don't merge that just yet

[10:35:42.0000] <nox>
annevk: I think that's the point.

[10:35:47.0000] <nox>
annevk: Parsers don't put things in templates.

[10:35:55.0000] <nox>
annevk: That's what Safari and Firefox do.

[10:38:36.0000] <annevk>
nox: have you tested what kind of mutation observer records they give?

[10:38:54.0000] <annevk>
nox: they would be kind of inconsistent I guess if they don't do a clean replace

[10:39:39.0000] <annevk>
nox: otherwise the innerHTML setter taking the returned nodes and then if it's invoked on a <template> using that to replace <template>.content might make more sense

[10:39:56.0000] <annevk>
nox: not sure what Hixie's thoughts are

[10:40:04.0000] <nox>
annevk: Mmh, makes sense indeed.

[10:40:09.0000] <nox>
annevk: Or not.

[10:40:23.0000] <nox>
Nested templates would end up with the wrong template contents owner document, I think.

[10:41:57.0000] <annevk>
Hmm where would that other document come from?

[10:43:01.0000] <nox>
annevk: Mmh right, never mind.

[10:43:22.0000] <nox>
annevk: Your idea means running adopting the whole tree again from another document though, maybe that's a bit too much post-processing?

[10:46:23.0000] <annevk>
nox: adopting is mostly changing a pointer

[10:46:32.0000] <annevk>
nox: and not doing this means weird mutations

[10:47:24.0000] <nox>
annevk: Yeah I know, but that's still traversing a tree once more. :P

[10:47:51.0000] <annevk>
nox: do you actually need to run it though?

[10:48:04.0000] <annevk>
nox: could have fast paths for a ton of this stuff

[10:48:13.0000] <annevk>
nox: mutation observers is important because it's observable from JavaScript

[10:48:37.0000] <nox>
annevk: The nested templates in the fake document will end up in the fake document's appropriate template contents owner document.

[10:48:50.0000] <nox>
The nested templates' template contents* sorry.

[10:48:56.0000] <nox>
So yes, they need to be re-adopted, AFAICT.

[10:49:31.0000] <nox>
annevk: I guess mutation observers see nothing about the template contents through innerHTML on a template, will check tonight at home.

[10:50:45.0000] <annevk>
nox: you could even have innerHTML reset .content

[10:51:18.0000] <annevk>
nox: rather than replace all...

[10:51:18.0000] <nox>
annevk: What do you mean?

[10:51:49.0000] <annevk>
nox: you take the return value of the HTML fragment parsing algorithm, run adopt, and stick it on .content

[10:53:02.0000] <nox>
Not sure, it would be surprising if you had a hold on .content before.

[10:53:17.0000] <annevk>
Yeah, replace all is better

[10:53:18.0000] <nox>
annevk: And it makes even weirder mutations, IMO.

[10:53:31.0000] <annevk>
well you wouldn't see any...

[10:53:51.0000] <nox>
Yeah, no one would notice the change, given there is nothing related to templates in mutation observers.

[10:54:08.0000] <nox>
Whereas if someone is observing the template contents, replace all would do the trick.

[11:38:34.0000] <Domenic>
annevk OK, good thing I got stuck in meetings for an hour :)

[11:38:51.0000] <Domenic>
IDL return types are basically non normative docs anyway though...

[11:55:02.0000] <poosanth>
Anyone know any good articles for folks starting out with trying to wrap their head around wcag 2

[11:59:23.0000] <wanderview>
jsbell: are you ok with this change to the Cache wpt tests? https://critic.hoppipolla.co.uk/r/5748

[12:16:06.0000] <SimonSapin>
TabAtkins: "it might take a few days" was not very nice of you :)

[12:23:05.0000] <jsbell>
wanderview: looking...

[12:23:49.0000] <wanderview>
jsbell: basically new Request() is now spec'd to throw if userpass are in the url

[12:24:00.0000] <wanderview>
so it blows up trying to setup the test corpus before running any tests

[12:25:05.0000] <jsbell>
wanderview: yeah, looks good, just seeing what we did in our copy... (or maybe we haven't implemented that yet)

[12:25:28.0000] <wanderview>
jsbell: ideally we would test for the Request constructor in the fetch wpt tests once we get them upstreamed

[12:25:36.0000] <wanderview>
for the credentials in the constructor

[12:27:16.0000] <jsbell>
Ah, we haven't implemented that change yet, which is why our tests still have those cases. :P

[12:27:22.0000] <jsbell>
crbug.com/474439

[12:28:52.0000] <jsbell>
wanderview: lgtm'd

[12:29:14.0000] <wanderview>
thanks!

[12:32:59.0000] <TabAtkins>
SimonSapin: "few" is a variable term 😀

[12:34:00.0000] <SimonSapin>
TabAtkins: I’ve heard guesstimates around 1500

[12:35:11.0000] <TabAtkins>
Seems plausible

[12:38:11.0000] <jsbell>
wanderview: note the comment #2 in that issue though... a SW could intercept a fetch made with credentials in the URL and put() (etc) the Request into a cache

[12:39:16.0000] <wanderview>
jsbell: hmm... I thought FetchEvent was spec'd to run Request constructor

[12:40:58.0000] <jsbell>
wanderview: doesn't seem to be... and it'd be weird if intercepts couldn't handle that...

[12:41:05.0000] <wanderview>
jsbell: yea, you are correct

[12:48:04.0000] <wanderview>
jsbell: should we reopen this review then?

[12:50:08.0000] <jsbell>
wanderview: IMHO a separate one would be fine. I'd need to be in a different file anyway

[12:50:19.0000] <wanderview>
k, thanks again

[13:00:37.0000] <wanderview>
jsbell: thanks for pointing that out... we have a bug where we run Request::Constructor() when creating FetchEvent...

[13:00:40.0000] <wanderview>
/me adds it to the list...

[13:02:57.0000] <wanderview>
annevk: are there any other restrictions in Request::Constructor() besides url userpass that you would expect html and other specs to bypass?

[13:04:01.0000] <wanderview>
annevk: I guess it would be nice to have a "create a Request" function that other specs go through that has expected assertions... like only simple methods ever passed for no-cors, etc

[13:04:59.0000] <nox>
annevk: WebKit patches innerHTML directly.

[13:05:46.0000] <nox>
annevk: Ah no wait, that's just calling the serializer.

[13:06:47.0000] <nox>
annevk: When serialising, the spec says "If the node is a template element, then let the node instead be the template element's template contents (a DocumentFragment node).", so I would expect parsing to be the same way too.

[15:54:13.0000] <heycam>
annevk, sounds fine (the unsigned long thing)

[15:59:56.0000] <MikeSmith>
hola heycam

[16:00:08.0000] <heycam>
hi MikeSmith

[16:03:48.0000] <MikeSmith>
heycam: seems there will be a lot of the #whatwg crew going to TPAC this year

[16:04:04.0000] <MikeSmith>
sort of a "we're getting the band back together"

[16:04:05.0000] <heycam>
MikeSmith, oh great! I won't be there unfortunately.

[16:04:10.0000] <MikeSmith>
ah!

[16:04:13.0000] <MikeSmith>
dang

[16:04:22.0000] <heycam>
my graduation ceremony is on the Wednesday

[16:04:29.0000] <roc>
woohoo!

[16:04:31.0000] <MikeSmith>
ah wow

[16:04:34.0000] <MikeSmith>
yeah man

[16:05:19.0000] <heycam>
I couldn't find any flights that would let me attend that enough of the rest of the week in Sapporo :)

[16:05:21.0000] <MikeSmith>
#whatwg should toast heycam while having a drink together at TPAC

[16:05:43.0000] <heycam>
I'll Skyp^WFirefox Hello in from the stage

[16:05:49.0000] <MikeSmith>
heh

[16:05:59.0000] <MikeSmith>
heycam: yeah some things you can't time ideally

[16:09:14.0000] <MikeSmith>
heycam: I also will not be able to attend TPAC this year

[16:09:23.0000] <MikeSmith>
due to my wife and I having a baby on the way around that time

[16:09:37.0000] <heycam>
MikeSmith, oh, congrats!

[16:09:49.0000] <MikeSmith>
thanks 😄

[16:10:06.0000] <heycam>
that is something you have (had) some degree of control over the timing of, though ;)

[16:10:17.0000] <MikeSmith>
heh

[16:10:23.0000] <MikeSmith>
true

[16:10:31.0000] <MikeSmith>
but I guess it's fitting that my baby already just can't manage to get with the program at W3C and time/do things with W3C harmony

[16:10:40.0000] <MikeSmith>
runs in the family

[16:11:24.0000] <heycam>
heh yeah, need a baby moratorium

[16:11:40.0000] <MikeSmith>
haha

[16:12:16.0000] <MikeSmith>
I think that would be good problem for the TAG to put their attention into trying to solve

[16:13:56.0000] <MikeSmith>
speaking of problems, I think the first thing I'm going to buy my baby will be a tiny T-shirt with the sentence "Solve real problems." printed on it

[16:16:40.0000] <roc>
but then how will your child get a PhD?

[16:16:52.0000] <MikeSmith>
roc: zing :)

[16:22:39.0000] <MikeSmith>
/me goes back to hacking on Hixie's bash and perl code


2015-09-04
[17:17:37.0000] <nox>
annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18794

[17:27:48.0000] <nox>
annevk: https://github.com/w3c/webcomponents/commit/c3c46d87f9764a746523ec17853b0a5eb5ed46e0

[19:35:14.0000] <Liki>
hello, i'm trying to use github/fetch but have a question about how to capture an event from the response?

[19:35:38.0000] <Liki>
more specifically, i'm uploading a file and it returns the progress event

[19:44:38.0000] <MikeSmith>
Liki: add an event listenert for "fetch", use respondWith() to do something?

[19:44:56.0000] <MikeSmith>
ah, progress event

[20:19:21.0000] <Liki>
Hi so there is no such event mechanism just like those in Superagent?

[20:22:08.0000] <MikeSmith>
Liki: dunno what Superagent is

[20:22:27.0000] <MikeSmith>
that github/fetch library is just a polyfill isn't it?

[20:22:50.0000] <MikeSmith>
that is, it just provides exactly the same API as what's in the Fetch standard

[20:22:56.0000] <MikeSmith>
and nothing additional

[20:23:13.0000] <MikeSmith>
e.g., no convenience methods or whatever

[20:23:31.0000] <MikeSmith>
Liki: have you read the spec? https://fetch.spec.whatwg.org/

[20:24:50.0000] <MikeSmith>
botie, inform Liki https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

[20:24:51.0000] <botie>
will do

[20:24:56.0000] <MikeSmith>
(in case he comes back)

[21:07:57.0000] <annevk>
nox: well, maybe I know what I'm doing after all

[21:34:14.0000] <mkwst>
annevk: Morning. :)

[21:34:53.0000] <mkwst>
annevk: For MIX: how do I check whether a request is targeting an iframe? I used to look at the frame type, now I need to ... what? Look at the client's document's ancestors?

[21:35:19.0000] <mkwst>
s/document/browsing context/

[22:34:42.0000] <annevk>
mkwst: yes, basically

[22:35:04.0000] <annevk>
mkwst: you need to check the ancestor anyway right for its URL?

[22:50:49.0000] <annevk>
So Directory Upload should really just be a patch to HTML

[22:50:55.0000] <annevk>
Anyone want to point that out?

[22:51:18.0000] <annevk>
And the webkit* stuff might need to be added to compat.spec.whatwg.org by miketaylr or also straight to HTML...

[22:54:54.0000] <mkwst>
annevk: Is the client for a request that's navigating an iframe the iframe itself, or the document embedding the iframe.?

[22:56:22.0000] <annevk>
mkwst: that's a good question, there was a similar thing with your "originating origin" or some such right?

[22:56:49.0000] <annevk>
mkwst: I learned recently Gecko has two principals, requesting and loading or some such... I guess we might need both?

[22:57:01.0000] <mkwst>
Probably. I'm just confused about what I'm supposed to be looking at now.

[22:57:22.0000] <mkwst>
I guess? Previously, I was just relying on magical 'frame type' settings.

[22:57:50.0000] <mkwst>
That was simpler, as it pushed the complexity onto you/HTML. :)

[22:57:52.0000] <annevk>
mkwst: what's the setup in Chrome?

[22:59:08.0000] <mkwst>
Currently? Still frame type. :)

[22:59:50.0000] <annevk>
mkwst: so it matters for referrer for instance

[23:00:09.0000] <annevk>
if you have a link in parent that targets the child and follow that, the referrer is the parent

[23:00:28.0000] <annevk>
if you have a link in child that targets the child/parent and follow that, the referrer is the child

[23:00:43.0000] <mkwst>
We throw all the data we need for Referrer into the request, and then do any stripping in the network stack.

[23:01:24.0000] <mkwst>
which boils down to the requesting URL and policy.

[23:02:15.0000] <mkwst>
Because the network stack lives way above Blink, and has no way of digging back down into the execution.context.

[23:02:28.0000] <annevk>
Yeah that makes sense

[23:02:52.0000] <annevk>
But we currently set referrer to "client"

[23:03:19.0000] <annevk>
Hmm...

[23:04:17.0000] <annevk>
And then the referrer specification does all kinds of tricks with request's client

[23:04:33.0000] <annevk>
But you want to do tricks with the "loading" client

[23:04:41.0000] <mkwst>
That is what the spec does. I'm not sure if any browser does. :)

[23:05:08.0000] <annevk>
Yeah, I guess we could pull some of that logic back in HTML too...

[23:05:36.0000] <annevk>
I'm just trying to figure out what a better setup would be

[23:06:03.0000] <annevk>
I think the easiest would be to introduce an additional client

[23:06:12.0000] <annevk>
Since service workers also wants the "loading" client, afaict

[23:06:21.0000] <annevk>
JakeA: ^^

[23:06:27.0000] <annevk>
I'm somewhat surprised nobody noticed this before

[23:06:53.0000] <annevk>
Well maybe I shouldn't be, review of Fetch and Service Workers is notoriously poor

[23:07:24.0000] <mkwst>
The whole integration with navigation seems a bit hand-wavey.

[23:07:58.0000] <mkwst>
But hey! We can fix it all now!

[23:10:35.0000] <JakeA>
We're punting fetchEvent.client to v2, so we can make changes here

[23:11:28.0000] <annevk>
So either we introduce "requesting client" or "loading client" next to "client" but some specifications will need to change

[23:11:57.0000] <annevk>
Oooh

[23:12:00.0000] <annevk>
I know

[23:12:44.0000] <annevk>
Well, hmm, I was thinking "navigating client" as the client that initiates the navigation, but that might as well refer to the client that is navigating...

[23:13:14.0000] <annevk>
"navigate requesting client"?

[23:13:48.0000] <annevk>
Because this is only needed for Fetch resulting from a navigate attempt... It would mean that referrer policy needs to if/else on the two clients

[23:14:02.0000] <annevk>
But that doesn't seem too bad?

[23:14:32.0000] <annevk>
It also means that mkwst can just continue to use client as he wants to in Mixed Content and that the current Service Worker setup is correct too

[23:14:44.0000] <annevk>
And this should be what CSP wants too

[23:19:27.0000] <mkwst>
I think that sounds right. Let me get to my desk and think about it.

[23:38:59.0000] <annevk>
Domenic: mind if I take over your top-links work and finish it?

[23:39:34.0000] <annevk>
mkwst: certainly, once you tentatively approve I'll file a bug on Fetch and Referrer

[23:39:44.0000] <annevk>
mkwst: thankfully you got to this before I started rewriting HTML

[23:40:09.0000] <mkwst>
I'm only looking at it now because you're making me rewrite MIX. So, thank _you_, I guess? :)

[23:40:29.0000] <Domenic>
annevk: ah, I knew there was something I dropped on the floor in the last couple days. Sure, go ahead, since now is supposedly sleepytime for me.

[23:43:40.0000] <Domenic>
The other thing on my to do list is to respond to https://github.com/whatwg/html/issues/62 ... we shouldn't leave issues unanswered like that for too long

[23:44:09.0000] <annevk>
Fortunately mkwst hangs out here

[23:44:26.0000] <annevk>
My main problem there is lack of interest from other vendors

[23:45:09.0000] <mkwst>
So, for MIX, I thing I really only care about the context making the request. iframes don't actually matter, because they're just like every other blockable subresource request.

[23:45:41.0000] <mkwst>
For CSP, I need to know both the context making the request (to apply the correct policy), and that the request is targeting an iframe (to know to apply `child-src`)

[23:46:34.0000] <mkwst>
Referrer Policy needs to know the context making the request (for the origin/cross-origin distinction, and the referrer policy). I'm not sure it needs to care what context is being targeted.

[23:47:07.0000] <mkwst>
Domenic: What annevk said. I floated that proposal a million years ago on Specifiction and WHATWG. Crickets.

[23:47:45.0000] <mkwst>
Domenic: Once Firefox has a reasonable process model they may be more interested, as one of the things it would allow us to do is to keep passwords in the browser process, so that a corrupted renderer couldn't get direct access.

[23:48:01.0000] <mkwst>
Domenic: And it's a mild protection against XSS stealing form data directly.

[23:48:32.0000] <mkwst>
Domenic: Since it's trivial to implement, I think it's worth doing. Especially since the opaque FormData bits of it are necessary for credential management anyway.

[23:49:04.0000] <mkwst>
So it's really just more or less defining an attribute, and cutting off JavaScript access to `value`.

[23:51:33.0000] <Domenic>
Yeah but it's kind of a question of should it be in the spec if only one browser does it or is planning on doing it

[23:51:47.0000] <mkwst>
Not disagreeing with you. :)

[23:51:49.0000] <Domenic>
Which is a somewhat broader problem

[23:52:41.0000] <Domenic>
I am having vague 3am visions of rendered spec diffs or checkboxes to turn on experimental awaiting-implementations features while viewing the spec or something.

[23:52:58.0000] <dan2k3k4>
:o

[23:53:25.0000] <mkwst>
Go to bed. ;)

[23:53:28.0000] <Domenic>
Basically something better than these micro specs that monkeypatch HTML all over the place because they're extending HTML in some way

[23:53:55.0000] <Domenic>
At least I stayed up late for a good cause, namely computer games.

[23:54:12.0000] <mkwst>
Domenic: But I love monkey patching HTML! It's all I do!

[23:54:17.0000] <Domenic>
hehehe

[23:54:23.0000] <Domenic>
nn

[23:56:39.0000] <annevk>
mkwst: *waves hand* there is no context

[23:57:01.0000] <mkwst>
"context" => "{browsing, execution} context"

[23:58:53.0000] <annevk>
mkwst: ah okay, so it sounds like we're in agreement

[23:59:46.0000] <annevk>
Hopefully many years from now bz will look at this (because he's trying to sort something out) and will be not be like "what were you thinking?!"

[00:00:18.0000] <mkwst>
I'm going to need you to review the fetch bits in MIX. They're getting much more complicated than I'd like.

[00:00:27.0000] <annevk>
That's the kind of stuff that keeps you up at night

[00:13:56.0000] <mkwst>
I lied. I need the target context in MIX.

[00:14:12.0000] <mkwst>
Otherwise I can't exclude top-level navigation from mixed content checks.

[00:16:48.0000] <annevk>
Right, that client's corresponding browsing context is what you call "target context" I think

[00:16:56.0000] <annevk>
s/that//

[00:17:17.0000] <annevk>
I would call that "loading browsing context" or some such

[00:17:24.0000] <mkwst>
I thought `client` was the browsing context making the request?

[00:17:44.0000] <annevk>
No, that would be the new "navigate requesting client"

[00:18:11.0000] <annevk>
"navigate-requesting client"

[00:19:05.0000] <mkwst>
ok. so that will either be null (in the case that the request's target is not "document"), or the client that initiated the navigation?

[00:21:10.0000] <mkwst>
Hrm. This is somewhat strange. If I'm navigating an iframe, do I have an environment settings object yet? I don't think I do.

[00:21:44.0000] <mkwst>
Is `client` the settings object of the page that was previously in the frame? That I'm navigating away from?

[00:24:35.0000] <annevk>
mkwst: I think <iframe> will due to about:blank magic

[00:24:49.0000] <annevk>
mkwst: the top-level browsing might not always

[00:25:06.0000] <annevk>
mkwst: but yeah, maybe that's a bad setup

[00:26:04.0000] <annevk>
ugh

[00:26:20.0000] <vigneshh>
/me slaps vigneshh around a bit with a large fishbot

[00:35:35.0000] <mkwst>
annevk: Sanity check https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-fetch?

[00:41:49.0000] <annevk>
mkwst: that looks about right, with the caveat that client for <iframe> is broken

[00:43:39.0000] <mkwst>
Does it also make sense, or do I need to add more explanatory notes?

[00:46:32.0000] <annevk>
mkwst: 2.4.2 does not seem to be needed

[00:47:38.0000] <annevk>
mkwst: or is 2.4.2 specifically about same-origin? might be better to check for that then...

[00:48:28.0000] <mkwst>
We block insecure CORS requests in 2.3, so I guess 2.4.2 is probably irrelevant, yeah.

[00:48:54.0000] <annevk>
mkwst: it makes sense to me, but I'm not sure what that's worth

[00:49:35.0000] <mkwst>
annevk: if you, having written Fetch, didn't understand what I was doing, then it's hopeless. :)

[00:58:34.0000] <yhirano_>
annevk: I run "make" on the fetch spec repo, and it complains that some specs don't exist. Do I need to modify data/specs.json in the anolis directory? Is there any specs.json for the fetch spec uploaded?

[00:59:25.0000] <annevk>
yhirano_: do you have the xref repository?

[00:59:58.0000] <annevk>
yhirano_: that is, did you read https://wiki.whatwg.org/wiki/GitHub#Makefile?

[01:00:20.0000] <yhirano_>
annevk: thanks, i didn't, i will.

[01:04:59.0000] <yhirano_>
annevk: it works, thank you!

[01:05:17.0000] <annevk>
yhirano_: no worries, looking forward to the PR!

[02:13:33.0000] <annevk>
gsnedders: why did https://github.com/html5lib/html5lib-python/pull/126 never land?

[02:44:55.0000] <Titi_Alone>
Hello,

[02:44:55.0000] <Titi_Alone>
I've a question about the URL living standard, who should I contact?

[02:45:36.0000] <Ms2ger>
Ask

[02:46:03.0000] <Titi_Alone>
In the Ipv6 perser

[02:46:07.0000] <Titi_Alone>
*parser

[02:46:30.0000] <hsivonen>
nox: I didn't write <template> parsing support. wchen did. I don't have anything more useful to say than pointing at the code. Sorry.

[02:47:06.0000] <hsivonen>
annevk: I'm writing the Big5 stuff in Java first, since I want to have an Encoding Standard impl. in Java, too, eventually.

[02:47:22.0000] <Titi_Alone>
In the Ipv6 parser section, the only thing to do if Ipv4 is the things written on line 8?

[02:47:57.0000] <hsivonen>
annevk: also, it's nicer to deal with bugs in Java first and then port over to C++, since it's easier to test an individual class in isolation in the Java context than in the XPCOM context

[02:48:12.0000] <annevk>
Titi_Alone: what do you mean by "If IPv4"?

[02:48:21.0000] <hsivonen>
annevk: I'm not autotranslating to C++ this time, though. Doing it manually.

[02:48:33.0000] <annevk>
Titi_Alone: the IPv4 part of an IPv6 address is handled by steps 8-10

[02:48:56.0000] <hsivonen>
annevk: as for Python, even rust-encoding uses Python to turn the indexes into array literals

[02:49:14.0000] <annevk>
hsivonen: do you use JSON as the input?

[02:49:21.0000] <hsivonen>
annevk: yes

[02:49:25.0000] <Titi_Alone>
Yes, that was my question, I thing the spec is unclear on this point

[02:49:33.0000] <hsivonen>
annevk: having JSON in the spec repo is awesome

[02:50:25.0000] <annevk>
Titi_Alone: "IPv4" there is just a marker

[02:50:41.0000] <hsivonen>
annevk: I use the .txt indeces only in a browser tab for visualizing patterns and for searching for interesting cases

[02:50:42.0000] <annevk>
Titi_Alone: if you have suggestions though, please file an issue :-)

[02:51:03.0000] <annevk>
hsivonen: yeah, me too, perhaps at some point we should flip what is normative

[02:51:14.0000] <Titi_Alone>
Don't you think that 9 and 10 should be substeps of 8?

[02:51:24.0000] <annevk>
Titi_Alone: no

[02:52:01.0000] <Titi_Alone>
Why? That's the case for Finale and Main.

[02:52:55.0000] <annevk>
Titi_Alone: no Finale is also steps 12 and 13

[02:53:36.0000] <annevk>
Titi_Alone: and Main is also step 7

[02:53:50.0000] <Titi_Alone>
Ok, that's really unclear for me.

[02:54:17.0000] <annevk>
Titi_Alone: it's just there so you can write "Jump to X"

[02:54:19.0000] <Titi_Alone>
The instructions for the marker to another marked belongs to the first marker ?

[02:54:25.0000] <annevk>
Titi_Alone: they don't mean anything else

[02:54:45.0000] <annevk>
Titi_Alone: when reading a specification you should never try to read meaning into things, only read what it says, literally

[02:56:54.0000] <Titi_Alone>
I'll try, but here, I was thinking Ipv4 was just the instruction 8.

[02:57:32.0000] <Titi_Alone>
Thanks for telling me that was not the case, anyway.

[02:58:04.0000] <annevk>
Titi_Alone: no worries, and again, if you have a way of saying the same thing but clearer, don't hesitate to let me know :-)

[02:58:21.0000] <annevk>
Titi_Alone: or provide a PR, even

[02:59:25.0000] <Titi_Alone>
annevk: Maybe precising somewhere at the begin or at the end of the spec that these are juste markers?

[03:00:02.0000] <annevk>
Titi_Alone: would it have helped you if there was a note just after the IPv6 parser algorithm saying so?

[03:00:06.0000] <annevk>
Titi_Alone: I can add such a note right now

[03:01:03.0000] <Titi_Alone>
annevk: What do you mean, a note?

[03:02:29.0000] <annevk>
<p class="note no-backref">To be clear, <a lt='IPv6 parser Main'>Main</a>,

[03:02:31.0000] <annevk>
<a lt='IPv6 parser IPv4'>IPv4</a>, and <a lt='IPv6 parser Finale'>Finale</a> are simple markers.

[03:02:31.0000] <annevk>
They serve no purpose other than being a location the algorithm can jump to.

[03:02:36.0000] <annevk>
Titi_Alone: something like that ^^

[03:03:14.0000] <Titi_Alone>
annevk: Yes, that would be really helpful.

[03:03:42.0000] <annevk>
Titi_Alone: should I list you as "Titi_Alone" in the acknowledgments or would you prefer another nick or actual name?

[03:04:06.0000] <annevk>
Titi_Alone: see https://url.spec.whatwg.org/#acknowledgments

[03:05:38.0000] <Titi_Alone>
annevk: Yes, Titi_Alone suits me

[03:07:33.0000] <Titi_Alone>
Is there another point where there are such markers in the spec?

[03:08:07.0000] <annevk>
Titi_Alone: I think only IPv6 uses them

[03:08:15.0000] <annevk>
Titi_Alone: committed the note

[03:10:12.0000] <Titi_Alone>
Thanks, that clarifies the spec.

[03:12:38.0000] <Titi_Alone>
annevk: I also have another question, when a "living standard" becomes a standard?

[03:12:57.0000] <Ms2ger>
It is a standard

[03:13:12.0000] <Ms2ger>
It says so right in the name: "Living >>>Standard<<<"

[03:14:07.0000] <Titi_Alone>
But why is it living?

[03:14:14.0000] <Titi_Alone>
*"living"

[03:14:26.0000] <annevk>
Titi_Alone: because it's never done

[03:14:45.0000] <Titi_Alone>
So it will always be a living standard?

[03:15:11.0000] <annevk>
Titi_Alone: ideally, unless URLs somehow disappear in which case it would become a Dead Standard, but that seems unlikely

[03:16:39.0000] <Titi_Alone>
Ok, that's great, thanks you.

[03:41:34.0000] <nox>
annevk: Shouldn't we just kill the references to DOM-Parsing and define innerHTML and outerHTML ourselves?

[03:42:07.0000] <annevk>
nox: we used to: https://github.com/whatwg/domparsing

[03:42:11.0000] <annevk>
nox: but Ms2ger gave up

[03:42:19.0000] <nox>
annevk: What do you mean?

[03:43:33.0000] <annevk>
nox: the W3C forked our work and made a better standard

[03:44:04.0000] <annevk>
nox: I do think it would be better to have this defined as part of HTML/DOM, but there's many things to fix

[03:45:31.0000] <nox>
annevk: Ok.

[03:45:54.0000] <nox>
annevk: I just meant that for innerHTML and outerHTML btw.

[03:46:33.0000] <nox>
Or just innerHTML, it's only 2 steps,

[03:47:03.0000] <annevk>
nox: well, there's also a getter

[03:47:15.0000] <nox>
Mmh, right.

[03:47:30.0000] <annevk>
nox: anyway, not sure it makes sense to define those separately and separately from createContextualFragment() and such

[03:47:38.0000] <nox>
Sure.

[03:47:44.0000] <annevk>
nox: and you might be forgetting about innerHTML on XML nodes

[03:47:50.0000] <nox>
Right.

[03:48:06.0000] <annevk>
also, PRs accepted

[03:48:12.0000] <nox>
annevk: So we won't chnage anything in the syntax chapter, right?

[03:48:30.0000] <annevk>
nox: for <template>?

[03:48:34.0000] <nox>
Yes.

[03:48:46.0000] <annevk>
I haven't seen any issues reported against it

[03:49:33.0000] <nox>
annevk: Cool.

[03:49:45.0000] <nox>
annevk: Just asked to close the corresponding html5ever bug. :)

[04:01:03.0000] <zcorpan>
what do we do with bugs like https://www.w3.org/Bugs/Public/show_bug.cgi?id=29041

[04:03:37.0000] <hsivonen>
zcorpan: how did Chrome come to allow that? bug? they just made stuff up without a spec bug?

[04:03:57.0000] <hsivonen>
also, allowing <template> in <frameset> seems sad

[04:04:09.0000] <nox>
The real question is, why did they even need such a thing?

[04:04:47.0000] <nox>
Feel free to ping me when you see things about templates that are wrong in the spec, given I implemented them in Servo this week, I would prefer if my implementation is interoperable. :)

[04:04:57.0000] <mkwst>
hsivonen: You can't trust Chrome folks. They're crazy.

[04:17:13.0000] <annevk>
zcorpan: we should get Chrome to fix it

[04:17:28.0000] <annevk>
zcorpan: and maybe test it in html5lib?

[04:17:30.0000] <annevk>
s/maybe//

[04:18:10.0000] <annevk>
/me added a comment to the bug

[04:18:14.0000] <zcorpan>
hsivonen: i don't know

[04:20:22.0000] <annevk>
hsivonen: https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fwhatwg%2Fhtml%2Fpull%2F101&sa=D&sntz=1&usg=AFQjCNHcrkfoj8uLlM7mfH07I6NwiQtJOA

[04:20:31.0000] <annevk>
hsivonen: https://github.com/whatwg/html/pull/101

[04:20:36.0000] <annevk>
hsivonen: ignore that first link

[04:22:40.0000] <zcorpan>
it looks like chrome implemented the early template spec. http://www.w3.org/TR/2013/WD-html-templates-20130214/#in-frameset-addition - http://w3c-test.org/html/semantics/scripting-1/the-template-element/template-element/template-descendant-frameset.html

[04:23:59.0000] <zcorpan>
/me files a bug

[04:32:36.0000] <annevk>
zcorpan: ta

[04:39:41.0000] <gsnedders>
annevk: because of all the html5lib tests being broken

[04:39:54.0000] <gsnedders>
annevk: because html5lib-python is miles behind in implementation terms

[04:40:04.0000] <annevk>
gsnedders: oh that sounds bad

[04:40:05.0000] <gsnedders>
annevk: so I have no trust that the PR doesn't break other things

[04:40:23.0000] <annevk>
gsnedders: that PR is actually wrong compared to other impls

[04:40:50.0000] <gsnedders>
can you comment as much?

[04:42:50.0000] <annevk>
gsnedders: done

[04:43:42.0000] <gsnedders>
thanks

[04:44:03.0000] <gsnedders>
fixing html5lib-python is a fair way down to to-do list

[04:44:18.0000] <gsnedders>
stuff dealing with html5lib-tests is currently at the top

[05:00:10.0000] <nox>
annevk: insertAdjacentHTML should be patched too, I think.

[05:16:45.0000] <annevk>
nox: yeah, seems like it

[05:17:43.0000] <annevk>
gsnedders: perhaps you should make sure html5lib-tests covers http://w3c-test.org/html/semantics/scripting-1/the-template-element/template-element/template-descendant-frameset.html too

[06:00:15.0000] <gsnedders>
annevk: yeah, we're probably missing a fair bit of stuff

[06:00:18.0000] <gsnedders>
annevk: esp. around template

[06:01:23.0000] <nox>
annevk: The good thing is that we don't really need tests for template fragments.

[06:01:54.0000] <annevk>
nox: heh, I guess there's always an upside of sorts

[06:01:59.0000] <nox>
In html5lib-tests I mean.

[06:02:31.0000] <gsnedders>
nox: why not?

[06:02:36.0000] <nox>
We should have some for the template insertion modes, but that's small.

[06:02:55.0000] <nox>
gsnedders: I mean the behaviour of setting innerHTML, that's outside of the scope of the tree builder tests, right?

[06:05:00.0000] <gsnedders>
nox: we have tests for that!

[06:05:11.0000] <gsnedders>
nox: #document-fragment, etc.

[06:05:39.0000] <nox>
gsnedders: Yes but that's not innerHTML, is it?

[06:05:56.0000] <gsnedders>
nox: ok, not /quite/

[06:06:06.0000] <gsnedders>
it's the fragment parsing algorithm

[06:06:08.0000] <nox>
The parsing of a template fragment doesn't involve the template contents of said template.

[06:06:16.0000] <nox>
Yes.

[06:07:26.0000] <gsnedders>
https://html.spec.whatwg.org/#parsing-html-fragments is what we have tests for

[06:07:32.0000] <gsnedders>
which IIRC innerHTML is a tiny wrapper around

[06:07:46.0000] <nox>
Yes. With a special case for templates.

[06:10:09.0000] <gsnedders>
where's the special case there?

[06:10:16.0000] <gsnedders>
the spec doesn't define one AFAICT?

[06:11:53.0000] <zcorpan>
r? https://critic.hoppipolla.co.uk/r/5785

[06:19:42.0000] <gsnedders>
nox: I can't see any special case for templates in the innerHTML spec?

[06:19:59.0000] <nox>
gsnedders: https://github.com/w3c/DOM-Parsing/issues/1

[06:20:36.0000] <nox>
gsnedders: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18794

[06:20:41.0000] <nox>
https://github.com/w3c/webcomponents/commit/c3c46d87f9764a746523ec17853b0a5eb5ed46e0

[06:21:01.0000] <gsnedders>
why aren't we patching this a tthe HTML level?

[06:21:39.0000] <nox>
gsnedders: Because innerHTML is defined there. It used to be patched at the HTML level when webcomponents was a thing.

[06:22:17.0000] <nox>
Anyway, I was just saying that's not a matter for the fragment parsing algorithm itself.

[06:22:34.0000] <gsnedders>
my point is why doesn't the fragment parsing algorithm fix it?

[06:22:45.0000] <gsnedders>
because surely that's the common point where all these things go through?

[06:26:15.0000] <nox>
gsnedders: Because it would be extremely weird.

[06:26:21.0000] <nox>
gsnedders: The fragment parsing just parses.

[06:26:34.0000] <nox>
gsnedders: Now it would need to replace all the template contents of some template node.

[06:30:54.0000] <Ms2ger>
annevk, r? https://github.com/whatwg/html/pull/103

[06:39:17.0000] <Ms2ger>
TabAtkins, ~1500 person-days to implement the entire HTML spec?

[06:42:05.0000] <jgraham>
6 people 1 year?

[06:42:10.0000] <jgraham>
Sounds implausible

[06:42:22.0000] <jgraham>
/me doesn't know the context

[06:48:36.0000] <espadrine>
the context is https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Sep/0019.html

[06:49:12.0000] <espadrine>
and https://twitter.com/brucel/status/639720876099944448

[06:50:50.0000] <nox>
Ms2ger: Just saw https://github.com/whatwg/html/pull/103, nice!

[06:51:04.0000] <nox>
Ms2ger: It is blocked by a DOM issue though.

[06:51:20.0000] <nox>
Ms2ger: https://github.com/whatwg/dom/pull/66

[06:53:05.0000] <Ms2ger>
I guess it is, yes

[07:22:07.0000] <Ms2ger>
https://twitter.com/webkit/status/639800468475125760

[07:22:13.0000] <Ms2ger>
Now import them all

[07:30:25.0000] <gsnedders>
nox: oh, right, because it just returns the child nodes of root

[07:30:28.0000] <gsnedders>
nox: I'm an idiot

[07:30:31.0000] <gsnedders>
nox: ignore me

[07:30:38.0000] <Ms2ger>
gsnedders, news? :)

[07:30:45.0000] <gsnedders>
Ms2ger: shush you

[07:30:50.0000] <nox>
Ah ah.

[07:31:27.0000] <gsnedders>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3620 — why does Gecko's parsing alter with the removal of one <foo> tag?

[07:31:42.0000] <gsnedders>
I don't think that should hit an AAA limit?

[07:31:48.0000] <gsnedders>
But I don't have the AAA swapped in atm

[07:32:49.0000] <gsnedders>
or is this hitting the inner loop counter?

[07:32:51.0000] <gsnedders>
hmmm

[07:34:08.0000] <gsnedders>
also why does the aside end up as a child of the div? is that AAA reparenting again?

[07:34:29.0000] <gsnedders>
Reviewing these tests seems to be AAA hell :)

[07:40:54.0000] <gsnedders>
nox: so I'm not entirely sure what exactly the document-fragment tests are meant to test now :P

[07:41:07.0000] <gsnedders>
nox: I think it's the return value of the document fragment parsing algorithm

[07:41:30.0000] <nox>
gsnedders: What do you mean?

[07:42:22.0000] <gsnedders>
jgraham: is there any way to force Critic to let it review "own" changes

[07:42:48.0000] <jgraham>
gsnedders: Yeah, if you mark yourself as a reviewer

[07:45:13.0000] <gsnedders>
jgraham: https://critic.hoppipolla.co.uk/r/5781 won't let me review?

[07:46:29.0000] <Ms2ger>
I don't know that I ever got that to work

[07:46:53.0000] <jgraham>
gsnedders: Now?

[07:47:04.0000] <gsnedders>
wfm now

[07:47:08.0000] <gsnedders>
jgraham: what did you do?

[07:47:25.0000] <jgraham>
I went to "manage assignments" and unchecked/checked you for all files

[07:48:48.0000] <gsnedders>
how do I select text in Critic again? holding down shift is doing weird stuff

[07:49:29.0000] <jgraham>
Hold down some key that doesn't do weid stuff? Popup a dialog and select in the other content

[07:49:32.0000] <jgraham>
?

[07:50:06.0000] <Ms2ger>
Alt

[07:53:44.0000] <annevk>
TabAtkins: :-(

[07:53:49.0000] <annevk>
TabAtkins: I update Bikeshed

[07:54:07.0000] <annevk>
TabAtkins: now EventTarget links to http://www.w3.org/TR/uievents/#interface-EventTarget rather than staying an internal link

[07:54:55.0000] <annevk>
TabAtkins: CustomEvent too

[07:55:13.0000] <annevk>
TabAtkins: even Event

[07:55:46.0000] <TabAtkins>
lolwut

[07:57:01.0000] <annevk>
I mean it's great that we got spaces back, but ...

[07:58:13.0000] <TabAtkins>
That sounds super weird. I'll check it out.

[07:59:44.0000] <annevk>
It also adds trailing whitespace...

[07:59:58.0000] <annevk>
E.g., <td><a data-link-type="dfn" href="https://encoding.spec.whatwg.org/#iso_8859_5">iso-8859-5</a> gets a space added at the end

[08:02:16.0000] <TabAtkins>
Inside of the <a>, or after?

[08:05:50.0000] <TabAtkins>
annevk: Well, I'll check it out.  Current DOM source?

[08:05:58.0000] <annevk>
TabAtkins: yes

[08:06:07.0000] <annevk>
TabAtkins: after </a>

[08:16:00.0000] <Krinkle>
/me risks asking a dangerously stupid question. With w3c and whatwg both being on github now, the borders between them seem fuzzier than they used to be.

[08:16:39.0000] <Hixie>
where the data is stored doesn't really have any bearing on how different they are :-)

[08:17:00.0000] <Krinkle>
Previously it appeared the key specs were maintained by whatwg to eventually be approved/published on w3 later.

[08:17:34.0000] <Hixie>
it's been a long time since any of the whatwg editors agreed to that really

[08:17:36.0000] <Krinkle>
but now e.g. preload is drafted under w3c directly

[08:18:21.0000] <Hixie>
most web specs are written at the w3c directly, they're a much bigger organisation :-)

[08:18:30.0000] <Hixie>
e.g. the csswg alone produces more spec than the entire whatwg

[08:18:46.0000] <Krinkle>
Oh you mean whatwg is, you know, a wg?

[08:19:16.0000] <Krinkle>
The rouge clan that left the nest :P

[08:19:37.0000] <Hixie>
dunno about rouge

[08:19:52.0000] <Krinkle>
Hehe

[08:19:58.0000] <gsnedders>
jgraham, Ms2ger: sorry for the email spam

[08:20:55.0000] <Ms2ger>
More specs or more spec? :)

[08:21:05.0000] <Krinkle>
Anyhow, I think I like the end result. There seems to be more harmony now. In that both entities seem to have authority (as recognised by developers and vendors) over their respective specs. E.g. new stuff in dom goes in whatwg/dom and is implemented from there.

[08:21:21.0000] <Hixie>
Krinkle: there's a lot of history between the two groups, and 12+ years of the people involved in the whatwg trying to work with the w3c in various ways

[08:21:37.0000] <Hixie>
so there's no simple story to tell

[08:21:55.0000] <Hixie>
while the w3c fork the whatwg html spec, though, i wouldn't proclaim world peace.

[08:24:13.0000] <Krinkle>
It's great that these things can happen though. Vendors are not obligated to any sort of W3 license. Consensus and in the end, the users/vendors decide what they implement for the open web.

[08:25:18.0000] <Krinkle>
I was mostly asking in the context of source maps, which I'd like to see moved from google docs to a git repo.

[08:25:38.0000] <gsnedders>
more template, table fun…

[08:25:53.0000] <Krinkle>
Hixie: Is it obvious to you which entity would maintain that? (And if so, how can you tell?)

[08:26:02.0000] <gsnedders>
nox, annevk: is there any easy way to find all your recent template bugs?

[08:26:23.0000] <annevk>
gsnedders: that DOM-Parsing one ended up being the only one

[08:26:24.0000] <nox>
gsnedders: I linked the relevant bits in the DOM-Parsing one.

[08:26:45.0000] <annevk>
gsnedders: well, and there was that issue jgraham spotted this morning, about <frameset> and <template>

[08:27:01.0000] <Hixie>
Krinkle: not sure what you mean. maintain what?

[08:27:23.0000] <jgraham>
s/jgraham/zcorpan/?

[08:27:53.0000] <gsnedders>
annevk: think I've found another…

[08:27:58.0000] <Krinkle>
Hixie: The Source Maps standard. If that were to become a spec, is there a natural fit in either w3c or whatwg, based on who authors it or based on the subject matter..?

[08:28:03.0000] <annevk>
jgraham: yes

[08:28:09.0000] <annevk>
gsnedders: oh, please tell!

[08:28:39.0000] <gsnedders>
have as a doc: "<template><a><table><a>". consider the execution of "appropriate place for inserting a node" during the second <a>.

[08:28:48.0000] <Hixie>
Krinkle: dunno what that is

[08:28:53.0000] <annevk>
Krinkle: no, it's more about what you care about as editor

[08:29:04.0000] <gsnedders>
We hit "If last table has a parent node, then let adjusted insertion location be inside last table's parent node, immediately before last table, and abort these substeps."

[08:29:09.0000] <Krinkle>
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/  https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?hl=en_US&pli=1&pli=1

[08:29:11.0000] <annevk>
Krinkle: e.g., one of the things I care about is CC0

[08:29:15.0000] <annevk>
Krinkle: the W3C won't have it

[08:29:19.0000] <gsnedders>
but we aren't really inserting it within last table's parent node

[08:29:44.0000] <annevk>
Krinkle: another thing I care about is not being subject to the whims of the W3C AC

[08:30:12.0000] <nox>
gsnedders: How is it not last table's parent node?

[08:30:35.0000] <gsnedders>
nox: compare with what step 3 says

[08:30:46.0000] <Krinkle>
annevk: Right. So in terms of subject, it could fall under either. But it's up to the spec authors to choose where they want it, and to w3c/whatwg whether they want to own it.

[08:31:22.0000] <bblfish>
hi

[08:31:23.0000] <gsnedders>
nox: we want something like "if last table has a parent node and it is a template element, then let adjusted insertion location be inside last table's parent node's template contents, immediately before last table, and abort these substeps."

[08:32:00.0000] <bblfish>
How does one discuss security misunderstandings if one cannot do so publically?

[08:32:04.0000] <Hixie>
Krinkle: the whatwg doesn't really "own" the specs it publishes. it just asks the specs' editors to commit to keeping the specs maintained.

[08:32:16.0000] <bblfish>
In particular https://github.com/whatwg/html/issues/102

[08:33:19.0000] <Krinkle>
Hixie: Hm.. I see.

[08:33:40.0000] <Krinkle>
Does whatwg hire employees or contractors, or is it all volunteer based?

[08:34:10.0000] <Hixie>
Krinkle: entirely voluntary (if you count companies like google paying people to work on things "volunteering")

[08:34:21.0000] <Krinkle>
Right

[08:34:33.0000] <Hixie>
Krinkle: i pay the hosting costs out of pocket, iirc anne pays the certificate costs out of pocket

[08:34:41.0000] <Hixie>
i think that's it, cost-wise

[08:34:45.0000] <Krinkle>
but whatwg as its own entity does not have spendings on human resources.

[08:34:52.0000] <Krinkle>
cool

[08:34:58.0000] <Hixie>
whatwg as its own entity is not really an entity at all :-)

[08:35:27.0000] <annevk>
Yeah, we're not a legal entity, just a community

[08:35:41.0000] <Krinkle>
Yeah, I forgot for a second that many of the whatwg rock stars are full-time employed with this as part of their job.

[08:36:33.0000] <Krinkle>
Cool.

[08:36:39.0000] <Hixie>
bblfish: generally one gets a job as a security vendor and then talks about it with other security vendors :-)

[08:36:40.0000] <Krinkle>
I suspected as much, but wasn't sure. It's well organised :)

[08:37:04.0000] <Hixie>
bblfish: i'm only tangentially involved with security discussions so i'm not really the one to ask

[08:37:13.0000] <bblfish>
that sounds like the Australian rule that security has to be government licences. Crazy.

[08:37:56.0000] <annevk>
Krinkle: well, the nice thing about being able to set your own course is that you can do things properly and are not subject to folks that are not actually involved much

[08:38:07.0000] <annevk>
Krinkle: that was a major problem for me at the W3C

[08:38:45.0000] <annevk>
Krinkle: very hard to change things, whereas here you're much more empowered to tackle things

[08:38:47.0000] <Hixie>
bblfish: i certainly admit that in this case anyone using <keygen> is probably so hosed that it doesn't really matter either way

[08:39:04.0000] <bblfish>
@Hixie I understand. I hope you can see how secrecy in security can be used to make decisions that are bad for security.

[08:39:29.0000] <Hixie>
bblfish: secrecy anywhere can be used to make bad decisions. Transparency in security can also be used to steal billions of dollars.

[08:39:34.0000] <Hixie>
unlike in most other places.

[08:39:55.0000] <gsnedders>
annevk: do you want a bug for the above?

[08:40:20.0000] <annevk>
gsnedders: issue, please

[08:40:31.0000] <gsnedders>
annevk: on gh?

[08:40:33.0000] <annevk>
gsnedders: and thank you

[08:40:47.0000] <annevk>
gsnedders: https://github.com/whatwg/html/issues/new

[08:40:55.0000] <annevk>
gsnedders: Bugzilla is closed for business

[08:41:15.0000] <bblfish>
Hixie: that's all upside down. Security only works through transparency. That is why people use open protocols and mathematics for security. It's well known that security through obscurity is the worst.

[08:41:27.0000] <gsnedders>
annevk: bah, I use bug/issue interchangably :)

[08:41:55.0000] <Hixie>
bblfish: ok. if i ever accidentally come across your bank credentials, i should make sure to discuss these on a public list, yes? and for full transparency i should include them all.

[08:42:05.0000] <bblfish>
Furthermore the flaws in MD5 were demonstrated openly by top cryptographers working very carefully in 2008

[08:42:28.0000] <bblfish>
here we are not discussing a flaw: we are discussing a non existent flaw

[08:42:42.0000] <bblfish>
Ie a misunderstanding of how things work

[08:42:47.0000] <bblfish>
there is no security problem

[08:43:11.0000] <bblfish>
but the feat that there may be one is being used to remove security aspects from browsers.

[08:43:18.0000] <bblfish>
Just think about how crazy that is.

[08:43:19.0000] <Hixie>
so if I come across your bank password but think it's not your bank password, I should feel free to discuss it anyway? even if it turns out to actually be your bank password?

[08:43:34.0000] <Hixie>
the security issue really isn't why <keygen> is being removed

[08:43:40.0000] <Hixie>
it's just a minor issue amongst many bigger ones

[08:44:09.0000] <Hixie>
honestly i'm shocked that anyone is using <keygen>. Until I unilaterally decided to spec it, it was entirely non-standard.

[08:44:28.0000] <Hixie>
and nobody, nobady at ALL, was making the SLIGHTEST complaint about that fact.

[08:44:44.0000] <gsnedders>
jgraham: https://critic.hoppipolla.co.uk/r/5781 — can you review the two lines that are pending?

[08:44:52.0000] <gsnedders>
jgraham: because, like, they genuinely are my work

[08:44:59.0000] <bblfish>
The MD5 argument is part of a number of bad arguments being launched against keygen. It's a matter of divide and conquer.

[08:45:13.0000] <bblfish>
You should be ashamed to be putting such arguments forward.

[08:45:52.0000] <bblfish>
And even more so of not allowing discussion of it.

[08:45:57.0000] <Hixie>
ok. in the interests of solving this issue, please consider that i now think <keygen> is entirely secure.

[08:46:32.0000] <Hixie>
are you satisfied with the current situation, or does that not change anything?

[08:46:57.0000] <bblfish>
That's a step forward.

[08:48:17.0000] <bblfish>
If we make more steps like this we'll be able to get at the root of the issue, and perhaps find a solution that will allow browsers to be more secure and compete correcly against apps.

[08:48:35.0000] <bblfish>
and also help solve some major issues of security on the web.

[08:48:47.0000] <Hixie>
not really, since the reason the spec says it's going to be removed is that the browser vendors said it was going to be removed, and i'm not a browser vendor

[08:49:22.0000] <bblfish>
It's not brwoser vendors per se. It's a vocal group of people in the browser vendor space who are playing a dangerous game

[08:49:25.0000] <Hixie>
the only thing that would change my mind regarding whether the spec's current text is appropriate is finding out that it was wrong, which would mean finding out that the browser vendors were in fact NOT planning on removing it.

[08:49:47.0000] <Hixie>
the "vocal group of people in the browser vendor space" are "the people who get to make that decision"

[08:49:49.0000] <bblfish>
YEs, but for that to happen we need to make sure that the arguments are clear

[08:50:28.0000] <Hixie>
the fact that they're "vocal" is useful for us, but they could just as easily have silently removed the feature without comment and it wouldn't affect this situation (well, I guess it would have removed the feature faster rather than having a warning put in place first)

[08:50:55.0000] <Hixie>
the only argument i care about is "what are the browsers doing". so arguing with me about the technical aspects of the feature does nothing.

[08:51:00.0000] <bblfish>
what is happening seems a type of social hacking (cracking): you play one group against an other, and keep things in the dark to get something done that nobody would accept if they understood the full issue.

[08:51:14.0000] <Hixie>
i'm really not trying to play any group against any other

[08:51:20.0000] <Hixie>
i'm not even trying to play

[08:51:28.0000] <bblfish>
yes, you are not. Other people are doing the social hacking.

[08:51:46.0000] <Hixie>
ok... not sure why you're bringing it up with me though :-)

[08:51:52.0000] <bblfish>
But you are allowing it to happen, by for example closing issues like https://github.com/whatwg/html/issues/102 within 15 minutes.

[08:52:05.0000] <bblfish>
Wait that was not you who close it.

[08:52:08.0000] <Hixie>
that issue was entirely unactionable

[08:52:29.0000] <Hixie>
it made zero requests for change to the spec, and presented no arguments to justify any changes to the spec.

[08:52:55.0000] <Hixie>
as such, that it stayed open for 15 minutes means we were slacking :-)

[08:53:12.0000] <bblfish>
I am not a WHATWG professional. Perhaps one could find a way to diffuse the MD5 fear with some text.

[08:54:31.0000] <bblfish>
That keygen part is missing a diagram explaining how keygen is actually used.

[08:54:46.0000] <Hixie>
the keygen spec is only very barely a spec

[08:54:53.0000] <bblfish>
it works though.

[08:54:54.0000] <gsnedders>
jgraham: thx

[08:55:01.0000] <Hixie>
see above regarding how i unilaterally wrote it based on what scant documentation i could find

[08:55:09.0000] <Hixie>
despite nobody seeming to care one wit about whether it was specced or not

[08:55:11.0000] <bblfish>
thanks for doing that.

[08:55:16.0000] <bblfish>
I cared

[08:55:20.0000] <bblfish>
Tim Berners Lee cared

[08:55:24.0000] <Hixie>
lol no he didn't

[08:55:34.0000] <gsnedders>
jgraham: …now for trying to work out that one remaining issue

[08:55:40.0000] <Hixie>
he's the director of a standards organisation that ignored it for 10+ years

[08:55:53.0000] <bblfish>
he opened a thread on the Technical Architecture Group about it https://lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html

[08:56:01.0000] <Hixie>
if he cared, he would have done something about it, rather than just accidentally forking my work when i did it

[08:56:10.0000] <Hixie>
i mean nobody cared when i specced it

[08:56:18.0000] <Hixie>
it's cheap to care when it's being removed

[08:56:22.0000] <Hixie>
it means nothing

[08:56:55.0000] <bblfish>
I did not myself understand the misunderstandings that the current text could lead to

[08:56:58.0000] <Hixie>
(and the TAG means nothing too, so posting to the TAG about a removal is like the Inception of meaning nothing)

[08:57:33.0000] <Hixie>
the md5 thing really isn't the issue here.

[08:57:51.0000] <Hixie>
anyway. this has exceeded my quota for such discussions for the day.

[08:57:56.0000] <bblfish>
I think people were expecting the security specialists to help out here.

[08:57:58.0000] <Hixie>
this conversation cannot cause the spec to change.

[08:58:34.0000] <TabAtkins>
The md5 thing is *part* of why *browsers* want to remove it. It has nothing to do with why the spec is removing it - that's because the browsers want to remove it.

[08:58:50.0000] <bblfish>
yes, but it is a mistaken part

[08:58:59.0000] <bblfish>
and the other parts are IMHO mistaken too.

[08:59:00.0000] <TabAtkins>
Telling us won't help anything.

[08:59:01.0000] <Ms2ger>
/me yawns

[08:59:02.0000] <Hixie>
/me hands the baton over to tab and goes to take a shower (unrelated to this conversation!)

[08:59:12.0000] <TabAtkins>
Hixie: But I need to take a shower too! Noooooooo!

[08:59:14.0000] <gsnedders>
The spec probably isn't the right place to convince the browsers who want to remove it.

[08:59:18.0000] <Hixie>
mwuhahaha

[08:59:31.0000] <bblfish>
yes, that is indeed why a discussion at the TAG is helpful

[08:59:32.0000] <gsnedders>
Because likely nobody who is removing it from browsers will notice.

[08:59:39.0000] <Ms2ger>
Uhuh

[08:59:44.0000] <bblfish>
Security is a complex area.

[08:59:51.0000] <Ms2ger>
Because the TAG has been so effective

[08:59:53.0000] <bblfish>
IT really requires all to work together.

[08:59:54.0000] <gsnedders>
And nobody who is removing it from browsers will ntoice a discussion a t the TAG.

[09:00:21.0000] <bblfish>
Well if you know of better avenues for discussion I am ready

[09:00:32.0000] <TabAtkins>
Well, new TAG is useful.  It also supports <keygen> removal. ^_^

[09:00:57.0000] <gsnedders>
bblfish: I'd speak to those who made the decision to remove it from browsers

[09:01:00.0000] <Ms2ger>
You can always try to convince people in the bink-dev thread

[09:01:09.0000] <Domenic>
TAG is a pretty good black hole for such discussions

[09:01:20.0000] <espadrine>
bblfish: whatever fundamental reason that webid can no longer be implemented (in js or otherwise) without keygen is an issue you should raise to browser vendors

[09:01:32.0000] <espadrine>
clinging to keygen is likely hopeless

[09:01:34.0000] <bblfish>
You mean Harry Halpin does. He has a vested interest as he pushed the JS crypto spec. But these don't actually solve the problem as written as they are missing Chrome ( ie User Interface ) elements.

[09:01:35.0000] <Domenic>
People who do not implement can argue in circles with each other on www-tag and feel like they've accomplished a lot

[09:01:55.0000] <Ms2ger>
It's the new public-html

[09:02:33.0000] <bblfish>
What is needed is a forum where all the different pieces can be looked at together.

[09:02:35.0000] <Domenic>
hah. so true.

[09:02:57.0000] <bblfish>
IT could be the WHATWG, but you only do what browsers appear to want.

[09:02:57.0000] <TabAtkins>
bblfish: No, what's needed is to convince the browser vendors to change their mind.

[09:03:02.0000] <TabAtkins>
Literally nothing else will do anything at all.

[09:03:11.0000] <bblfish>
yes, and where do you do that?

[09:03:37.0000] <Domenic>
blink-dev, moz.platform, Edge UserVoice, Safari ... Twitter?

[09:03:40.0000] <TabAtkins>
blink-dev, mozilla-dev, webkit-dev, wherever IE likes talking to people

[09:03:47.0000] <Domenic>
right that

[09:03:55.0000] <Ms2ger>
IE doesn't like talking to people

[09:04:14.0000] <Ms2ger>
But try blink/webkit first

[09:04:30.0000] <Domenic>
Edge is quite friendly these days; I'd prefer we not perpetuate old prejudices.

[09:04:50.0000] <bblfish>
ok, so there are a number of different forums. And one forum is WHATWG. There is a bit of text about MD5 that could help with discussions in the other forums.

[09:04:50.0000] <ato>
Does anyone know about UUID’s here?  There are different versions of it (1 though 5) and I’m wondering if it is sufficient to talk about “UUID” (as defined in RFC 4122) as a general concept, or if one should talk specifically about one version.

[09:04:55.0000] <Ms2ger>
/me is subscribed to the Gecko equivalent and would prefer to avoid more email about it

[09:05:11.0000] <gsnedders>
ato: They're all UUIDs and all interchangeable

[09:05:19.0000] <gsnedders>
ato: the type is encoded within the UUID

[09:05:50.0000] <gsnedders>
ato: generally you pick what type depending on a number of factors (anonmity of the generator, etc.)

[09:06:12.0000] <ato>
gsnedders: Does it make sense to pick the type?

[09:06:25.0000] <gsnedders>
ato: in a spec? why?

[09:07:02.0000] <ato>
gsnedders: To add some context, I don’t care about the interchange between UUIDs of different versions/types, as long as one type is inherently cohesive.

[09:07:25.0000] <gsnedders>
ato: they aren't really different "versions", they're different ways to generate a UUID

[09:08:13.0000] <ato>
gsnedders: Okay I see.

[09:08:20.0000] <nox>
gsnedders: I'm not sure I understand.

[09:08:29.0000] <gsnedders>
nox: about what? :)

[09:08:40.0000] <nox>
17:31 <gsnedders> nox: we want something like "if last table has a parent node and it is a template element, then let adjusted insertion location be inside last table's parent node's template contents, immediately before last table, and abort these substeps."

[09:08:54.0000] <nox>
"and abort these substeps."

[09:08:57.0000] <ato>
gsnedders: Thanks (-:

[09:09:04.0000] <nox>
Step 3 is "If the adjusted insertion location is inside a template element, let it instead be inside the template element's template contents, after its last child (if any)."

[09:09:37.0000] <gsnedders>
nox: step three doesn't apply here, no?

[09:09:39.0000] <ato>
gsnedders: Do you mind if I reference what you said?

[09:09:43.0000] <gsnedders>
ato: go ahead

[09:09:45.0000] <nox>
gsnedders: "substeps".

[09:09:53.0000] <ato>
gsnedders: Cheers

[09:09:56.0000] <nox>
The foster parenting substeps in step 2.

[09:10:24.0000] <TabAtkins>
ato: What kind of monster does reversed smilies?

[09:10:33.0000] <nox>
Mmmh, but actually, it doesn't apply anyway.

[09:10:38.0000] <TabAtkins>
ato: Particularly ones where all the characters exist in the normal orientation!

[09:10:40.0000] <ato>
TabAtkins: (-:{

[09:10:47.0000] <TabAtkins>
blocked

[09:10:53.0000] <ato>
TabAtkins: That’s my conspicuous smiley.

[09:11:09.0000] <TabAtkins>
In the real world, that's a mustachiod man wearing an umbrella hat. Get with the program.

[09:11:17.0000] <nox>
gsnedders: What's the issue exactly?

[09:11:21.0000] <ato>
TabAtkins: lol

[09:11:53.0000] <csarven>
Hixie Surely you've read my email now. Here it is in case it made it to the bin: https://gist.github.com/csarven/e5d190e82015f5f41b18 -- The point is that, WHATWG raised a concerned which was then clarified by bblfish.

[09:11:58.0000] <nox>
Actually, shouldn't it just be "If last table has a parent node, then let adjusted insertion location be inside last table's parent node, immediately before last table, and abort these substeps."?

[09:12:10.0000] <nox>
gsnedders: If the table was in a template, its parent node isn't the template anyway.

[09:12:21.0000] <gsnedders>
nox: am I being an idiot here? I think I am.

[09:12:30.0000] <nox>
gsnedders: Both. The spec too.

[09:12:48.0000] <nox>
We are discussing a Web spec anyway. We must be not very smart.

[09:12:58.0000] <gsnedders>
nox: So I think <template><table><a> is where the bug really is.

[09:13:07.0000] <nox>
gsnedders: If a table is parsed in a template, its parent cannot be a template.

[09:13:16.0000] <MikeSmith>
mkwst: I found a markup syntax error in your pr 93 source; is it OK with you if I just push a fix to the branch?

[09:13:21.0000] <nox>
Its parent can be a document fragment, in which case foster parenting should just work.

[09:13:28.0000] <MikeSmith>
mkwst: and in the future is that OK?

[09:13:29.0000] <nox>
Or another element, and that's not a problem either.

[09:13:34.0000] <gsnedders>
nox: why not?

[09:13:44.0000] <nox>
gsnedders: Because the parser never puts things in a template.

[09:13:45.0000] <gsnedders>
oh, right

[09:14:03.0000] <gsnedders>
that's not my confusion, gimmie a moment

[09:14:17.0000] <MikeSmith>
mkwst: (would take less time for me to just fix it, and generated less gihtub notification spam, etc.)

[09:15:23.0000] <Hixie>
csarven: see my comment earlier. please assume that i believe <keygen> is entirely secure.

[09:15:26.0000] <MikeSmith>
Hixie: wattsi error reporting is nice

[09:15:27.0000] <gsnedders>
nox: how does it's parent node because a document fragment?

[09:15:40.0000] <gsnedders>
nox: where in the spec is this?

[09:15:41.0000] <Hixie>
csarven: you can also assume that i think that <keygen> is the epitome of good design in every way.

[09:15:56.0000] <Hixie>
csarven: since it doesn't impact the discussion in the slightest

[09:15:59.0000] <Hixie>
MikeSmith: yeah?

[09:16:06.0000] <nox>
gsnedders: When you parse <table> after <template>,

[09:16:11.0000] <Hixie>
MikeSmith: anything in particular? it was a bit hit or miss in my experience :-)

[09:16:14.0000] <nox>
gsnedders: target is the current node, so <template>,

[09:16:32.0000] <MikeSmith>
Hixie: well it's helped me catch markup errors

[09:16:49.0000] <MikeSmith>
e.g., "Parse Error: (14571,170) unexpected end tag"

[09:16:54.0000] <nox>
gsnedders: Foster parenting is off (AFAICT),

[09:16:58.0000] <MikeSmith>
from mkwst PR 93

[09:16:59.0000] <Hixie>
MikeSmith: i know the build.sh script has some specific things to prevent ms2ger from getting annoyed at you :-)

[09:17:05.0000] <MikeSmith>
heh

[09:17:09.0000] <nox>
gsnedders: so directly step 3,

[09:17:12.0000] <MikeSmith>
Hixie: yeah, notcied that

[09:17:16.0000] <Hixie>
MikeSmith: ah, yeah, i had it output line,col so that emacs would jump to the problem spot

[09:17:19.0000] <gsnedders>
"If the adjusted insertion location is inside a template element, let it instead be inside the template element's template contents, after its last child (if any)."… does that make it's parent node the template contents?

[09:17:24.0000] <nox>
gsnedders: and thus <table> is inserted in the template contents.

[09:17:41.0000] <MikeSmith>
Hixie: it gets the job done

[09:17:42.0000] <Hixie>
MikeSmith: iirc i never fixed it to correct the line numbers to handle merging in other files though. :-(

[09:17:49.0000] <MikeSmith>
oh

[09:18:05.0000] <gsnedders>
nox: to me it's not clear that the "parent node" of something in the template contents *is* the template contents

[09:18:25.0000] <nox>
gsnedders: The template contents is a document fragment.

[09:18:33.0000] <gsnedders>
nox: where is /that/ defined?

[09:18:46.0000] <nox>
gsnedders: https://html.spec.whatwg.org/multipage/scripting.html#template-contents

[09:19:07.0000] <nox>
Follow the links, Luke. :P

[09:19:10.0000] <gsnedders>
bah!

[09:19:35.0000] <gsnedders>
the problem with following the links is you end up in an infinite loop!

[09:19:57.0000] <csarven>
Hixie Those opinions are in fact irrelevant to the discussion. Again, the point is that WHATWG raised 2nd hand concerns. It is pointed out that they are not based on facts, and that an appropriate explanation was provided. Therefore, why does the discussion suddenly stop :) Will you be issuing a new email stating that your previous statements had no grounds and that you acknowledge the explanation on Github? And yes, we can assume your

[09:19:57.0000] <csarven>
view on keygen and the changes to the spec as is.

[09:21:15.0000] <Hixie>
the point is my opinions here are entirely irrelevant

[09:21:25.0000] <Hixie>
the reason the spec changed is that the browser vendors said they were going to remove it

[09:21:29.0000] <Hixie>
end of rationale

[09:21:35.0000] <Hixie>
everything else is a distraction

[09:22:03.0000] <csarven>
Okie dokie.

[09:22:16.0000] <nox>
gsnedders: Anyway, I don't see how a template can be the parent of an element on the stack of open elements.

[09:24:59.0000] <gsnedders>
nox: does the template contents ever get pushed to the stack?

[09:25:01.0000] <gsnedders>
/me looks closely

[09:26:16.0000] <gsnedders>
nox: afaict, the template contents DocumentFragment never gets pushed onto the stack of open elements

[09:26:28.0000] <gsnedders>
probably in part because it's not an element :)

[09:33:07.0000] <nox>
gsnedders: Not a matter AFAICT.

[09:34:10.0000] <nox>
gsnedders: check is about the table parent, not the stack.

[09:35:07.0000] <nox>
gsnedders: Sorry missed that it was a just question. No I don't think it's ever pushed on the stack. And it shouldn't because it's not an element as you said.

[09:42:40.0000] <MikeSmith>
maybe we can get the www-tag cranks interested in discussing <applet> deprecation too

[09:54:19.0000] <annevk>
wanderview: wow, quick turnaround on setting User-Agent support

[09:54:52.0000] <wanderview>
annevk: it was not set as a priority... but mystor took it to get started with SW

[09:55:25.0000] <wanderview>
he's pretty fast :-)

[09:55:45.0000] <gsnedders>
nox: yeah, indeed

[09:56:15.0000] <MikeSmith>
mkwst: nm I forgot that PR branch is in your fork (so I can't push to it anyway)

[09:56:21.0000] <nox>
gsnedders: So parsing itself has no bug, AFAICT.

[09:56:33.0000] <MikeSmith>
we need a way to raise PRs against PRs!

[09:57:00.0000] <nox>
MikeSmith: You can do that already.

[09:57:13.0000] <MikeSmith>
nox: oh!

[09:57:15.0000] <nox>
Just make a PR against the branch tip.

[09:57:16.0000] <MikeSmith>
how?

[09:57:34.0000] <MikeSmith>
ok

[09:57:42.0000] <MikeSmith>
/me tries

[09:57:59.0000] <nox>
MikeSmith: But if the PR is merged, upstream is probably going to ask for a rebase or whatever.

[09:58:13.0000] <MikeSmith>
ah

[09:58:29.0000] <nox>
Because then you will have a PR merge in your PR.

[10:00:24.0000] <MikeSmith>
ok

[10:00:43.0000] <MikeSmith>
/me throws caution to the wind

[10:02:09.0000] <MikeSmith>
hmm, but in github I can't have a fork of somebody else's fork of an upstream repo I already have a fork of myself, right?

[10:03:17.0000] <MikeSmith>
I guess i'll just fork it to one of my other orgs/accounts

[10:05:50.0000] <nox>
MikeSmith: Yes you can.

[10:06:34.0000] <MikeSmith>
hmm, I don't see how in the GH UI

[10:06:37.0000] <nox>
MikeSmith: I'm pretty sure you can make PR on repositories that you didn't even fork.

[10:07:02.0000] <MikeSmith>
hmm, dunno how to do that, so I will just proceed with forking

[10:07:07.0000] <nox>
https://github.com/<user>/<repos>/compare/<base>...<PR user>:<PR branch>

[10:07:38.0000] <nox>
AFAIK, there is a link somewhere to do that from the UI, but I can't remember where it is.

[10:07:59.0000] <nox>
MikeSmith: Oh right, on the branches page, the Compare buttons.

[10:08:13.0000] <nox>
MikeSmith: You arrive on the compare view, but with 4 form controls instead of 2.

[10:08:27.0000] <MikeSmith>
/me looks

[10:08:46.0000] <nox>
The difference in the UI seems to be from /compare/<base> vs /compare/<base>...<PR user>:<PR branch>

[10:08:53.0000] <MikeSmith>
yeah

[10:09:03.0000] <nox>
MikeSmith: I don't know if that still exists,

[10:09:16.0000] <nox>
MikeSmith: but through the GH API you used to be able to upgrade your issues into PR too.

[10:09:23.0000] <MikeSmith>
oh

[10:09:27.0000] <annevk>
Hixie: thanks for the feedback on <ruby>

[10:09:36.0000] <MikeSmith>
nox: that's a nice feature

[10:09:51.0000] <nox>
http://stackoverflow.com/questions/4528869/how-do-you-attach-a-new-pull-request-to-an-existing-issue-on-github

[10:09:52.0000] <annevk>
Maybe I should figure out if I can have a chat with Richard, I think he's in my timezone roughly

[10:10:08.0000] <nox>
annevk: What's the feedback btw? Missed some backlog I guess.

[10:10:17.0000] <annevk>
nox: it was on GitHub

[10:10:29.0000] <annevk>
nox: to just make Ruby conforming

[10:10:43.0000] <nox>
annevk: So with the two missing tags?

[10:11:57.0000] <annevk>
nox: yeah, I wrote a patch for the parser, but made the elements non-conforming

[10:12:13.0000] <annevk>
nox: making the elements conforming is probably gonna be some work

[10:12:31.0000] <nox>
annevk: Where is that? Sorry can't find the issue/PR.

[10:19:23.0000] <annevk>
nox: there's only five open PRs :-) https://github.com/whatwg/html/pull/101

[10:20:06.0000] <nox>
annevk: Ok, I didn't expect HTML to get 4 PRs on the same day, so I looked only at the first, sorry. :P

[10:22:07.0000] <nox>
What's HTML51? :(

[10:23:27.0000] <jgraham>
It's the one that's 46 better

[10:23:36.0000] <nox>
lol

[10:23:47.0000] <annevk>
nox: http://www.w3.org/TR/html51/ (sometimes returns an error)

[10:24:01.0000] <nox>
Yeah saw it, but how does it fit in the grand scheme of things?

[10:24:28.0000] <annevk>
This might be the wrong place to ask that question

[10:24:46.0000] <annevk>
It's the W3C's semi-active fork of HTML, with some changes

[10:25:38.0000] <nox>
annevk: Ok.

[10:25:41.0000] <annevk>
As Hixie mentioned earlier we're not really happy that they continue to fork, but we don't want to prevent them doing it legally, since that would hurt other efforts

[10:26:59.0000] <nox>
Who is "they"?

[10:27:38.0000] <annevk>
The W3C

[10:44:19.0000] <MikeSmith>
http://stackoverflow.com/questions/32403763/combined-vim-modeline-emacs-local-variables-line-on-a-single-line

[10:44:22.0000] <MikeSmith>
by me

[10:44:48.0000] <MikeSmith>
I wish I could put a phat bounty on my own SO question and then pay myself all the points back

[10:45:13.0000] <MikeSmith>
nox: thanks for the SO link

[10:45:30.0000] <annevk>
MikeSmith: heh, do we need the closing -->

[10:45:38.0000] <annevk>
MikeSmith: because the comment actually continue I see

[10:46:32.0000] <MikeSmith>
we don't need the closing --> on that line as far as vim or emacs is concerned

[10:46:44.0000] <annevk>
MikeSmith: okay, do you want to make the change too?

[10:46:51.0000] <annevk>
:-)

[10:46:59.0000] <MikeSmith>
sure

[10:47:50.0000] <MikeSmith>
but I don't want to comment on that PR for fear of upsetting Domenic in his meeting while he's playing games on his mobile and the GH notifications interrupt his mobile gaming

[10:48:19.0000] <MikeSmith>
(but I will change it later, quietly)

[10:48:37.0000] <MikeSmith>
(after merging)

[10:49:00.0000] <MikeSmith>
(or before merging, if you want me to merge it)

[10:49:05.0000] <MikeSmith>
(which I can if you want)

[10:49:07.0000] <annevk>
MikeSmith: you could just do "Fix #105: Emacs config" and it'll close automatically

[10:49:21.0000] <MikeSmith>
sure

[10:50:00.0000] <MikeSmith>
but I mean I can pull it locally and make the additional fix in my branch with an --amend before I push it

[10:50:15.0000] <annevk>
Personally I think it's fine to bikeshed small changesd

[10:50:23.0000] <annevk>
Helps folks prepare for larger changes

[10:51:01.0000] <annevk>
MikeSmith: I'd prefer one commit, don't really care how you go about that though

[10:51:10.0000] <MikeSmith>
ok

[10:52:51.0000] <MikeSmith>
and yeah I don't mind a little small-change bikeshedding now and then either, but I want to be considerate of other peoples' workflow and avoid pain points/annoyances (however minor)

[10:53:51.0000] <MikeSmith>
also, about forking and for the benefit of people here, I should say:

[10:54:13.0000] <MikeSmith>
I am not happy about the W3C forks of WHATWG specs

[10:54:31.0000] <MikeSmith>
(where "not happy" would be a gross understatement)

[10:55:07.0000] <MikeSmith>
and what's more I plan to do a lot more to stop them from happening than I have in the past

[10:55:24.0000] <annevk>
/me unsubscribes from www-tag

[10:56:11.0000] <MikeSmith>
my strategy in the past was just to get mad and yell at people, but that obviously hasn't been effective so far

[10:56:32.0000] <MikeSmith>
so my new plan is to try to remain calm and be smarter about it

[10:56:48.0000] <annevk>
heh

[10:58:35.0000] <MikeSmith>
but all that said, I think there are some quality changes that got made in the W3C fork of the HTML spec

[10:58:52.0000] <MikeSmith>
principally by Steve Faulkner

[10:59:21.0000] <MikeSmith>
and we should review those and see if/how many we can port

[10:59:39.0000] <hsivonen>
annevk: I'm not opposed to speccing rtc if Blink and WebKit already special-case it in their parser(s)

[11:00:02.0000] <hsivonen>
annevk: I think I won't have time to actually review the PR tonight

[11:00:24.0000] <annevk>
hsivonen: Gecko doesn't? I thought we did too

[11:00:49.0000] <annevk>
hsivonen: there's no great rush, though the parser part of that PR is complete afaict

[11:07:24.0000] <hsivonen>
annevk: I don't recall what Gecko does

[11:26:16.0000] <hsivonen>
hmm. we have a python port of the "universal" chardet in m-c

[11:26:40.0000] <hsivonen>
TIL: "big5han" is a collation supported by the JS i18n API

[11:47:30.0000] <MikeSmith>
I wish github had a way that a repo could allow people to create and push to PR branches in that repo but not to master (or to whatever the default branch for the repo is)

[11:48:21.0000] <MikeSmith>
but I guess it's git that prevents that (not github)

[11:52:06.0000] <hsivonen>
the old HTML parser wasn't the only piece of Netscape-era code that's hard to follow and that is surprising in that it works/worked

[11:52:27.0000] <hsivonen>
annevk: did you take a look at the encoding converter code while writing the spec?

[12:09:06.0000] <nox>
MikeSmith: Mmmh,

[12:09:16.0000] <nox>
MikeSmith: the latest changes are going towards that.

[12:09:16.0000] <Philip`>
MikeSmith: That's not a fundamental limitation of git - e.g. you can use gitolite to add branch-based access control

[12:09:32.0000] <nox>
MikeSmith: https://github.com/blog/2051-protected-branches-and-required-status-checks

[12:09:34.0000] <Philip`>
(or Gerrit)

[12:10:42.0000] <nox>
"Can't be force pushed" + "Can't have changes merged into them until required status checks pass" are weird though.

[12:10:42.0000] <MikeSmith>
nox: thanks

[12:10:52.0000] <MikeSmith>
Philip`: ah, OK

[12:10:58.0000] <MikeSmith>
(hi Philip` btw)

[12:11:00.0000] <nox>
You can push, but you can't merge things through their UI, from my understanding.

[12:11:07.0000] <Philip`>
(Hello)

[12:12:13.0000] <MikeSmith>
ah https://github.com/blog/2051-protected-branches-and-required-status-checks looks great

[12:12:16.0000] <MikeSmith>
timely

[12:23:56.0000] <nox>
gsnedders: What are the serializer tests? Do they actually test "serialize document fragments"?

[12:31:57.0000] <annevk>
hsivonen: I'm not sure which encoding converter you're referring to

[12:32:18.0000] <annevk>
hsivonen: big5 was mostly based on research by philipj

[12:33:35.0000] <annevk>
MikeSmith: yes, that would be great, branches  but not master

[12:36:22.0000] <annevk>
"Are you arguing that MD5 is secure because you don't understand how it's not secure?"

[12:36:26.0000] <annevk>
<3 sleevi

[13:42:50.0000] <TabAtkins>
annevk: So, "trailling space" on that <a> is just a result of me omitting </td>; I omit all the end-tags I can get away with.

[13:42:58.0000] <TabAtkins>
Where are you seeing it as a problem?

[13:44:14.0000] <TabAtkins>
And when I generate the spec, I'm getting CustomEvent/etc linking locally like they should.

[13:44:29.0000] <TabAtkins>
Oh wait, let me update the data files.

[13:47:17.0000] <TabAtkins>
wtf, that is broken.

[13:47:21.0000] <TabAtkins>
wtf is this crap

[13:48:59.0000] <TabAtkins>
What the shit, this is something bizarre happening with anchor resolution.  (Nothing to do with any recent changes.)

[14:02:52.0000] <TabAtkins>
annevk: Ah, found it.  Ugh, UI Events has a <dfn> *pointing to DOM* (well, to DOM 4) that Shepherd now detects, and so DOM says "whoops, this interface is already defined, let's just link to it".

[14:04:33.0000] <TabAtkins>
Okay, so first step is for me to add the error-check from a while ago, forcing you to either add "partial" (denoting it should link) or one of the things indicating that this is forced.

[14:04:50.0000] <TabAtkins>
Second, I need to get UI Events editted to no-export that entire section.

[14:14:01.0000] <zcorpan>
maybe we should no-export the Dependencies section in html also

[14:29:01.0000] <TabAtkins>
Yes plz


2015-09-05
[17:31:01.0000] <MikeSmith>
is IndexedDB still not usable in practice in Safari?

[17:31:20.0000] <MikeSmith>
/me is wondering what the limitations actualy are

[19:43:22.0000] <MikeSmith>
I owe hober some Internet Points for muffing up his change to the HTML source (now fixed but broke the build in the interim)

[21:09:30.0000] <annevk>
TabAtkins: if you know you are omitting </td>, why the need for the space?

[21:25:17.0000] <annevk>
/me MikeSmith's revised build system

[21:25:23.0000] <annevk>
tries out /\

[21:36:33.0000] <TabAtkins>
annevk: Ah, there is indeed a trailing space in the source. There was whitespace there originally, and the serializer collapses WS to a single space.

[21:37:14.0000] <TabAtkins>
I do drop leading/trailing WS-only anonymous blocks, I suppose I could further drop leading/trailing WS text nodes.

[21:37:25.0000] <annevk>
Wait there's trailing space in the source?

[21:37:33.0000] <annevk>
That sounds unlikely, since my editor removes that

[21:37:58.0000] <annevk>
There's no trailing space in the source

[21:41:16.0000] <TabAtkins>
No, trailing WS. Like, a newline.

[21:43:00.0000] <TabAtkins>
Precisely why there's no WS on the <a> lines, just the <code> lines, I'm not sure without experimenting.

[21:43:28.0000] <annevk>
Oh, there is a newline, sure

[21:43:43.0000] <TabAtkins>
Anyway, I can clean it up a little bit more if you want.

[21:43:56.0000] <annevk>
I guess I'm not too bothered by that one

[21:44:10.0000] <annevk>
The UI Events change was more problematic, but apparently that's a Shepherd thing again

[21:44:21.0000] <annevk>
I think I might actually be more often hurt by Shepherd than anything else

[21:44:42.0000] <TabAtkins>
Distributed systems, man.

[21:51:16.0000] <annevk>
Yeah, but there should be some way that newly added specifications maybe get staged or some such or don't get to squat on somebody else

[21:51:46.0000] <annevk>
TabAtkins: so is UI Events updated in Shepherd yet?

[21:56:38.0000] <TabAtkins>
annevk: Looks like it!

[21:56:56.0000] <annevk>
Would be nice if there was some way to find out about those things

[21:58:02.0000] <TabAtkins>
Yeah, I think I'm handling the IDL <dfn>-or-<a> wrong right now.

[21:58:34.0000] <TabAtkins>
For starters, it assumes that people are using "partial" properly, which seems to be mostly wrong.

[22:04:40.0000] <TabAtkins>
Unfortunate consequence of scaling up from "CSSWG, and other things I more-or-less have control over" to "shit, specs all over the place now".

[22:05:50.0000] <TabAtkins>
This should be handleable, I just need to tweak to a little more defensive without wrecking usability.

[22:09:37.0000] <annevk>
MikeSmith: can you make https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm redirect to https://w3c.github.io/uievents/?

[22:15:26.0000] <MikeSmith>
yup

[22:15:40.0000] <MikeSmith>
Will do when I get back home

[22:15:55.0000] <MikeSmith>
out at lunch atm

[00:43:18.0000] <hsivonen>
annevk: Gecko's old converters in general. they are hard to read

[00:51:00.0000] <annevk>
hsivonen: ah yes, I did study those

[00:51:06.0000] <annevk>
hsivonen: and yes, they are not great

[00:51:37.0000] <annevk>
hsivonen: Rebel Opera had really great converter code

[00:54:28.0000] <roc>
"Rebel Opera"?

[00:55:40.0000] <annevk>
roc: Opera had this great marketing campaign about being the rebel browser

[00:56:07.0000] <annevk>
roc: I sorta feel image stopped being true once they adopted Chromium

[00:56:14.0000] <annevk>
that image*

[04:08:26.0000] <annevk>
I just read through the ruby use cases document and now I'm even more confused how we ended up in this situation

[04:35:37.0000] <gsnedders>
nox: ignore the serilaizer tests

[04:36:03.0000] <gsnedders>
nox: https://github.com/html5lib/html5lib-tests/issues/58

[04:45:36.0000] <nox>
gsnedders: Ok.

[05:42:03.0000] <annevk>
Domenic: thanks for merging all that in

[05:46:13.0000] <annevk>
Domenic: I know get "rm: illegal option -- -"

[05:46:18.0000] <annevk>
s/know/now/

[05:46:33.0000] <annevk>
Domenic: spelling out rm arguments might not actually be a thing?

[07:17:39.0000] <annevk>
MikeSmith: thanks so much for this fast building stuff

[08:47:38.0000] <MikeSmith>
annevk: glad we got it

[08:48:00.0000] <MikeSmith>
makes it much more pleasant to test changes

[08:55:54.0000] <MikeSmith>
I just set up a new macbook and build.sh --no-updates completes in 8 seconds on this machine (vs 14 seconds on my older macbook)

[08:57:36.0000] <MikeSmith>
but now even more than before I wish we used 80-character lines for the source

[08:58:23.0000] <MikeSmith>
because then I could actually have it in a side-by-side arrangement, two windows

[08:59:01.0000] <MikeSmith>
80 columns each (15-inch screen

[09:18:11.0000] <annevk>
So far I can only find evidence in Gecko that "new ruby" is implemented

[09:18:16.0000] <annevk>
http://mxr.mozilla.org/mozilla-central/source/layout/style/html.css#791

[09:18:51.0000] <annevk>
From https://github.com/WebKit/webkit/blob/master/Source/WebCore/css/html.css#L1133 it seems WebKit only implemented HTML parser changes

[09:19:03.0000] <annevk>
Reminds me a bit of the <section>/<h1> fiasco

[10:39:18.0000] <annevk>
esprehn: well, I guess the question is whether they are "known" or simply parsed

[10:39:41.0000] <annevk>
esprehn: e.g., <isindex> was always HTMLUnknownElement too, although as I understand it Chrome dropped support for that element entirely

[10:52:09.0000] <annevk>
3 more commits and whatwg/html is over 9000

[10:52:13.0000] <annevk>
OVER 9000

[10:54:34.0000] <wanderview>
annevk: that was fast

[10:55:15.0000] <annevk>
wanderview: I was just added emphasis

[10:55:20.0000] <annevk>
adding*, geez

[10:55:53.0000] <wanderview>
how much of that was just dealing with import logistics?

[10:57:43.0000] <annevk>
wanderview: there's prolly a dozen or so commits related to moving to GitHub

[10:58:17.0000] <annevk>
wanderview: if you view the commit history online you need to go to page 4 though before you see pre-GitHub history

[11:00:59.0000] <wanderview>
annevk: oh... I didn't realize it included pre-github history

[11:01:37.0000] <annevk>
wanderview: aah

[11:01:48.0000] <annevk>
wanderview: this is every commit since the initial SVN commit

[11:02:04.0000] <wanderview>
that seems more reasonable to me

[11:02:14.0000] <wanderview>
I thoguht you were saying you guys made 9000 commits in a couple weeks

[11:02:26.0000] <annevk>
hah

[11:05:18.0000] <hsivonen>
jgraham: Is there a guide for writing a Web Platform Test instead of a Mochitest such that it doesn't need to land upstream before it lands in m-c?

[11:05:46.0000] <hsivonen>
jgraham: or in general a guide for writing Web Platform Tests for people who know how to write Mochitests?

[11:06:15.0000] <annevk>
hsivonen: afaik you just get it reviewed, commit it, and "magic" takes over

[11:06:40.0000] <wanderview>
hsivonen: if you commit in mozilla-central/tests/web-platform/tests then it will get upstreamed automatically

[11:06:55.0000] <hsivonen>
annevk, wanderview: thanks

[11:07:02.0000] <hsivonen>
so is there a guide for actually writing tests?

[11:07:12.0000] <wanderview>
just a sec

[11:07:31.0000] <annevk>
hsivonen: http://testthewebforward.org/docs/

[11:07:44.0000] <wanderview>
/me is too slow

[11:07:52.0000] <hsivonen>
annevk: thanks

[11:08:16.0000] <annevk>
wanderview: did you drink your coffee yet? :-P

[11:08:39.0000] <wanderview>
annevk: yes... but its saturday and it was my morning with the kids

[11:08:42.0000] <hsivonen>
seems like it's not written as a guide for people who are used to mochitests, but OK

[11:09:30.0000] <wanderview>
hsivonen: yea, not really written from mochitest perspective

[11:09:47.0000] <wanderview>
hsivonen: best I can suggest is to look at an existing test and adapt it

[11:13:48.0000] <wanderview>
hsivonen: I guess there are some specifics to mozilla-central... for example, after you add your test you need to run add --manifest-update to the ./mach web-platform-tests command to get the test included in the list

[11:19:16.0000] <hsivonen>
wanderview: thanks. --manifest-update seems like an important thing that's not part of the general docs

[11:19:29.0000] <wanderview>
its mach specific

[11:19:38.0000] <wanderview>
./mach help web-platform-tests I guess

[11:22:00.0000] <MikeSmith>
hsivonen: yeah I do no think we yet have any specific docs written for an audience of people already familiar with writing mochitests. It would be nice to have some but in general the docs are targeted toward a baseline where we don't assume the contributer is yet familiar with anything (e.g., not reftests either)

[11:23:06.0000] <MikeSmith>
contributions (however small) to those docs are very welcome and can also earn you chocolate from jgraham

[11:23:35.0000] <MikeSmith>
a docs patch for --manifest-update would be nice to have

[11:26:15.0000] <hsivonen>
oh, nice. someone has already written a Web Platform Test for the gbk encoder

[11:26:19.0000] <hsivonen>
I guess I'll adapt that

[11:26:28.0000] <hsivonen>
it's less complex than whan I had in mind, too

[11:31:59.0000] <MikeSmith>
/me wonders who wrote that one

[11:49:45.0000] <MikeSmith>
hsivonen: git blame says the somebody who wrote that test is actually annevk

[11:50:22.0000] <wanderview>
that guy again

[12:28:16.0000] <esprehn>
annevk: if we have any behavior attached is shouldn't be an unknown element

[12:32:45.0000] <esprehn>
annevk: https://chromium.googlesource.com/chromium/blink/+/master/Source/core/html/HTMLTagNames.in#109

[12:32:57.0000] <esprehn>
the person who added those to the file just didn't read the spec which says HTMLElement

[12:47:42.0000] <annevk>
esprehn: do you have any behavior attached though?

[12:47:52.0000] <annevk>
esprehn: it seems that Chromium, like WebKit, just implemented changes to the parser

[12:49:42.0000] <esprehn>
annevk: ah yes, it seems we don't implement the behavior

[13:22:18.0000] <MikeSmith>
I had thought Koji Ishii had been working on implementing rb+rtc support. I guess I was wrong.

[13:23:16.0000] <MikeSmith>
the fact that nobody has actually implemented any of it for this long seems to point to it not actually being so necessary or useful, despite all the rhetoric to the contrary

[13:23:46.0000] <MikeSmith>
or at least, nobody cares about it enough to contribute code, or to pay somebody to implement it

[13:24:48.0000] <MikeSmith>
annevk: I'm wishing more and more that I shouldn't have just given up in that thread on dev-platform in March or whenever this was

[13:25:10.0000] <MikeSmith>
the Intent to Implement thread for rb+rtc

[13:25:44.0000] <MikeSmith>
anyway, not too late

[13:30:51.0000] <annevk>
MikeSmith: I think he (or someone else) did for Gecko

[13:31:07.0000] <annevk>
MikeSmith: but no other browser seems to have anything beyond parser changes...

[13:31:54.0000] <MikeSmith>
annevk: yeah, and given that, seems like the Gecko implementation may have been premature

[13:33:01.0000] <annevk>
MikeSmith: yeah

[13:33:07.0000] <annevk>
MikeSmith: it's quite the clusterfuck

[13:33:14.0000] <MikeSmith>
yeah :(

[13:34:42.0000] <MikeSmith>
IMHO in this particular case, if Apple hasn't implemented it and are not treating it as priority, then it's not actually a priority for any big publishers, etc., in Japan

[13:34:53.0000] <annevk>
https://github.com/whatwg/html/pull/112 is pretty cool

[13:35:03.0000] <MikeSmith>
/me looks

[13:35:15.0000] <annevk>
not sure we want to merge as-is, but saving over 80% in bandwidth seems huge

[13:35:47.0000] <MikeSmith>
oh wow yeah

[13:35:54.0000] <MikeSmith>
nice

[13:36:47.0000] <MikeSmith>
this stuff is kind of a black art

[13:36:55.0000] <MikeSmith>
glad somebody understands it

[13:39:05.0000] <MikeSmith>
but fwiw I think it's somewhat easier with nginx

[13:39:39.0000] <MikeSmith>
annevk: btw has there been some consideration about moving away from Apache to nginx

[13:39:56.0000] <MikeSmith>
Apache seems like kind of a sunk cost at this point

[13:39:57.0000] <annevk>
MikeSmith: I doubt nginx is RESTful though

[13:40:16.0000] <MikeSmith>
not sure in what way you mean

[13:40:32.0000] <annevk>
MikeSmith: trollish

[13:40:36.0000] <MikeSmith>
ah

[13:40:43.0000] <MikeSmith>
hahaha

[13:41:06.0000] <MikeSmith>
yeah, nginx certainly lacks one important personality

[13:41:09.0000] <annevk>
MikeSmith: I think if we found someone to maintain the servers we could maybe move

[13:41:14.0000] <MikeSmith>
ok

[13:41:18.0000] <annevk>
MikeSmith: but letting DreamHost manage all that is also somewhat convenient

[13:41:25.0000] <annevk>
MikeSmith: hmm, gotta go, nn

[13:41:30.0000] <MikeSmith>
well I'm not personally volunteering

[13:41:34.0000] <MikeSmith>
hai

[13:41:35.0000] <MikeSmith>
nn


2015-09-06
[23:36:32.0000] <mathiasbynens>
FWIW, Cătălin is the driving force behind https://github.com/h5bp/server-configs-apache/blob/master/dist/.htaccess. If anyone understands Apache configuration, it’s him

[00:19:22.0000] <kalimann>
hi, anybody know why my picture with transparency in it gets becomes greyed out in that area? instead of showing through to the white background

[00:20:54.0000] <cvrebert>
annevk: Apparent typo in title of https://github.com/whatwg/dom/issues/61 "Path" -> "Patch"

[00:39:57.0000] <kalimann>
hi can someone help me? :)

[00:40:03.0000] <kalimann>
"hi, anybody know why my picture with transparency in it gets becomes greyed out in that area? instead of showing through to the white background"

[00:44:56.0000] <kalimann>
like, only part of the image is invisible basically, and that will shown in image applications, but once i put it in the html it gets greyed out

[00:57:45.0000] <deltab>
kalimann: maybe it's not fully transparent, or maybe the element has a grey background

[00:58:17.0000] <deltab>
maybe the image was saved without transparency

[00:58:55.0000] <kalimann>
i fixed it. simple coding error. dumb mistake by me, sorry

[03:24:40.0000] <MikeSmith>
mathiasbynens: ah, yeah I thought I'd seen his name around before

[05:35:50.0000] <badmankali>
hi. im making a page now, where alot of elements are placed as theyre supposed to with css, with position: relative

[05:36:17.0000] <badmankali>
i have a small subtitle that i want to include next to the headline, but it moves everything insanely so when i insert it

[05:37:48.0000] <badmankali>
can i do it so with it moving everything, or should i change the other elements position tag to something else and readjust them, and then change it?

[05:49:23.0000] <nox>
annevk: Ping?

[05:49:50.0000] <nox>
annevk: Ms2ger pointed out to me that it was a bit scary to execute code on nodes of which children are in another document.

[05:50:02.0000] <nox>
annevk: Which is exactly what I did with my adopting steps patch,

[05:50:07.0000] <nox>
annevk: do you think that should be changed?

[06:29:23.0000] <annevk>
nox: maybe

[06:29:42.0000] <nox>
annevk: Can't find users of adopting steps but <template>, though.

[06:30:21.0000] <annevk>
nox: <img>

[06:30:34.0000] <nox>
Oh.

[06:32:32.0000] <nox>
annevk: Btw, the link of "adopting steps" directly goes to the DOM spec,

[06:32:46.0000] <nox>
annevk: isn't it supposed to link to the reference to the spec?

[06:56:35.0000] <annevk>
nox: not if the <dfn> has some kind of x-href attribute

[08:30:04.0000] <annevk>
I wonder where we should host some of the general WHATWG server configuration...

[08:30:43.0000] <annevk>
I guess we could create a "whatwg-servers" repository or some such with some information

[08:31:09.0000] <annevk>
It does seem that hosting such information inspires folks to contribute improvements

[08:50:27.0000] <annevk>
hsivonen: seems that only Gecko implemented ruby parser changes and style changes...

[09:03:48.0000] <MikeSmith>
annevk: apparently I now have enough juice on stackoverflow that I can create tags

[09:04:00.0000] <MikeSmith>
so I want to create one for Fetch

[09:04:35.0000] <MikeSmith>
shall it be fetch-standard or fetch-method?

[09:04:40.0000] <MikeSmith>
or something else?

[09:05:21.0000] <MikeSmith>
(I mean that people can use instead of or in addition to the existing generic "fetch" tag)

[09:06:05.0000] <MikeSmith>
and once I create I'll go back through some of the existing questions that are actually about Fetch, and add the tag to those

[09:07:39.0000] <annevk>
MikeSmith: we use fetchstandard on Twitter

[09:07:53.0000] <annevk>
MikeSmith: but maybe fetchapi is more catchy?

[09:08:24.0000] <annevk>
MikeSmith: I mean, I expect most questions will be about the API

[09:09:31.0000] <MikeSmith>
ok

[09:09:38.0000] <MikeSmith>
btw http://stackoverflow.com/search?q=https%3A%2F%2Furl.spec.whatwg.org%2F

[09:10:07.0000] <MikeSmith>
shows enough existing questions to justify a url-standard tag as well

[09:10:56.0000] <MikeSmith>
btw the convention at SO seems to be to use hyphens in multi-word tags afaict

[09:11:12.0000] <MikeSmith>
so I'll do fetch-api

[09:11:14.0000] <MikeSmith>
ok?

[09:11:42.0000] <MikeSmith>
"fetchapi" just looks odd anyway

[09:26:32.0000] <annevk>
Sure

[12:36:32.0000] <annevk>
http://stackoverflow.com/search?q=xhr.spec.whatwg.org shows that quite a few folks are being taught that synchronous IO is bad

[12:36:43.0000] <annevk>
Warning messages are rather effective

[13:36:30.0000] <caitp>
isnt "synchronous ajax" kind of nonsense?


2015-09-07
[22:02:26.0000] <kalimann>
brothers. how would you make a list like this? http://snag.gy/U0c5P.jpg

[22:03:06.0000] <kalimann>
with year numbers as bulletins, and then two different lines of info for each year

[22:03:21.0000] <kalimann>
i tried some nested lists but cant make it work

[22:04:16.0000] <kalimann>
should i just break it into different <p> or is there a systemical way to do this?

[23:05:34.0000] <renlinx>
hi..

[23:05:48.0000] <renlinx>
my github account is

[23:05:55.0000] <renlinx>
github.com/sideffect0

[23:10:05.0000] <annevk>
caitp: heh

[00:23:41.0000] <nox>
annevk: Made a PR for the issue I mentioned yesterday.

[01:25:00.0000] <MikeSmith>
mkwst: about the HTML CSP PR, gimme a second to rebuild from it and look at the rendered output

[01:25:14.0000] <mkwst>
MikeSmith: No rush. :)

[01:25:24.0000] <mkwst>
I'm sure it's broken. I'm still not building locally. :/

[01:25:34.0000] <mkwst>
Maybe I'll take some time to play with the new scripts y'all have put together.

[01:28:20.0000] <MikeSmith>
mkwst: yeah please do try out the script update and help test it

[01:29:50.0000] <MikeSmith>
mkwst: it's in the pr/20 branch there (aka sideshowbarker/redesign-output-input-split)

[01:31:14.0000] <MikeSmith>
mkwst: so yeah I "Parse Error: (14573,170) unexpected end tag" when building

[01:32:06.0000] <MikeSmith>
isn't that the line I sent you a PR for?

[01:32:07.0000] <mkwst>
Does it not like splitting the `span`'s attribute across lines?

[01:32:13.0000] <MikeSmith>
no, hang on

[01:32:14.0000] <mkwst>
Did you send me a PR?

[01:32:47.0000] <MikeSmith>
yeah https://github.com/mikewest/html/pulls

[01:33:11.0000] <MikeSmith>
https://github.com/validator/html/commit/3a47bf6209f3b7cee9773dec6b89142eae5cad22

[01:33:38.0000] <MikeSmith>
the fix is to remove "</dfn></dt>" from the end of that line

[01:33:52.0000] <MikeSmith>
you don't need to use my PR as such

[01:34:27.0000] <MikeSmith>
I just made that because I wanted to see if it was possible to make a PR against somebody else's PR branch

[01:35:37.0000] <mkwst>
Ok, the `</dfn>` is certainly wrong, thanks! I guess the rest of the file drops the `</dt>` as well, even though that style choice is objectively incorrect. :)

[01:36:03.0000] <MikeSmith>
right yeah, the "</dt>" is not wrong but Hixie style is to omit it

[01:36:21.0000] <MikeSmith>
(personally I like that style too)

[01:36:45.0000] <MikeSmith>
"objectively incorrect" :)

[01:37:03.0000] <mkwst>
Eh. It feels wrong not to close tags that are closable. That said, out of all the things in this file that annoy me, lack of some closing tags is hardly at the top of the list.

[01:37:03.0000] <MikeSmith>
but it's not a big deal to have it

[01:37:11.0000] <mkwst>
Dropped it from the latest commit.

[01:37:17.0000] <MikeSmith>
k

[01:37:37.0000] <Ms2ger>
Annoyingly, he doesn't drop </li>, though

[01:38:19.0000] <MikeSmith>
/me pulls

[01:38:50.0000] <MikeSmith>
Ms2ger: yeah but Hixie does that specifically you personally ;-)

[01:39:02.0000] <MikeSmith>
Ms2ger: yeah but Hixie does that specifically to annoy you personally ;-)

[01:39:13.0000] <Ms2ger>
I knew it

[01:40:01.0000] <annevk>
Ms2ger: it depends, </li> is sometimes dropped

[01:40:13.0000] <MikeSmith>
mkwst: build success but got some non-build errors

[01:40:16.0000] <hsivonen>
aargh. I can't reuse the Web Platform Tests gbk encoder test for Gecko, because the test assumes that the browser has a URL Standard-compliant URL parser, which Gecko doesn't have

[01:40:30.0000] <MikeSmith>
mkwst:

[01:40:33.0000] <MikeSmith>
Error: missing <dfn> for topic "reflected-xss" explicitly from <code> element containing "reflected-xss"; previous heading contents are "4.2.5.3 Pragma directives"

[01:40:36.0000] <MikeSmith>
Error: missing <dfn> for topic "report-uri" explicitly from <code> element containing "report-uri"; previous heading contents are "4.2.5.3 Pragma directives"

[01:40:39.0000] <MikeSmith>
Error: missing <dfn> for topic "frame-ancestors" explicitly from <code> element containing "frame-ancestors"; previous heading contents are "4.2.5.3 Pragma directives"

[01:40:42.0000] <MikeSmith>
Error: missing <dfn> for topic "sandbox" explicitly from <code> element containing "sandbox"; previous heading contents are "4.2.5.3 Pragma directives"

[01:41:01.0000] <mkwst>
can I not just have `code` elements? Do they need to reference something?

[01:41:07.0000] <MikeSmith>
annevk: ↑

[01:41:30.0000] <MikeSmith>
mkwst: empty

[01:41:32.0000] <MikeSmith>
oofs

[01:42:39.0000] <MikeSmith>
mkwst: <code data-x="">

[01:42:41.0000] <MikeSmith>
I think

[01:42:48.0000] <MikeSmith>
or something like that

[01:42:54.0000] <MikeSmith>
right annevk ?

[01:43:10.0000] <mkwst>
this document's conventions are so strange. :(

[01:43:20.0000] <annevk>
MikeSmith: yes

[01:43:53.0000] <annevk>
MikeSmith: though perhaps we should just add references for those since they're all terms defined by CSP

[01:44:09.0000] <MikeSmith>
mkwst: you will learn to love it eventually (stockholm syndrome)

[01:44:10.0000] <mkwst>
yeah, i'm adding references.

[01:44:19.0000] <MikeSmith>
k

[01:44:38.0000] <Ms2ger>
MikeSmith, not before it's been bikeshedded, I hope :)

[01:45:24.0000] <mkwst>
Are we bikeshedding? That would be nice!

[01:45:39.0000] <Ms2ger>
I hope we will

[01:46:11.0000] <mkwst>
How will you deal with the multipage version? That logic seems somewhat custom.

[01:46:44.0000] <MikeSmith>
mkwst: you don't need to necessarily

[01:46:53.0000] <MikeSmith>
except for your local testing

[01:46:58.0000] <MikeSmith>
ah you mean the xrefs

[01:47:05.0000] <MikeSmith>
I guess?

[01:47:08.0000] <mkwst>
and the generation.

[01:47:20.0000] <nox>
Why would he have written wattsi if it's for the spec to be bikeshedded afterwards, though?

[01:49:39.0000] <mkwst>
MikeSmith: So what do I need to build locally at the moment? Do I still need to build wattsi locally?

[01:53:14.0000] <MikeSmith>
mkwst: no you do not need a local wattsi at all

[01:53:28.0000] <MikeSmith>
Domenic put together a service that the build script now calls

[01:53:42.0000] <mkwst>
do I need to patch anything in?

[01:54:13.0000] <MikeSmith>
the build sends your source to the service, and the service returns a zip file and the build unpacks that and runs the rest of the build using that

[01:54:14.0000] <annevk>
mkwst: "valid Content Security Policy" is not defined

[01:54:34.0000] <MikeSmith>
mkwst: I think the trunk has that service change

[01:54:36.0000] <MikeSmith>
/me looks

[01:54:58.0000] <annevk>
Ms2ger: is Bikeshed fast enough?

[01:55:22.0000] <MikeSmith>
mkwst: yeah it does (I realize now I was the one who merged it...(

[01:56:12.0000] <MikeSmith>
mkwst: so yeah you don't need to build wattsi. run the script and it Should Just Work

[01:56:29.0000] <mkwst>
MikeSmith: Using the sideshowbarker/redesign-output-input-split branch?

[01:57:01.0000] <MikeSmith>
mkwst: you can if you want, though the trunk will also work for you

[01:57:10.0000] <MikeSmith>
but the sideshowbarker/redesign-output-input-split branch is faster

[01:57:20.0000] <mkwst>
faster === better.

[01:57:31.0000] <MikeSmith>
yeah it's quite a bit faster

[01:57:32.0000] <mkwst>
and it looks like it solves the "copy everything into this directory" problem?

[01:57:36.0000] <MikeSmith>
yes

[01:57:38.0000] <MikeSmith>
that too

[01:57:47.0000] <MikeSmith>
yeah

[01:58:02.0000] <MikeSmith>
you don't need to copy anything or symlink anything

[01:58:07.0000] <Ms2ger>
Bikeshed in Rust

[01:58:32.0000] <MikeSmith>
oh, you should set HTML_SOURCE to the relative path to your html repo

[01:58:55.0000] <MikeSmith>
or if you have one in ../html the build will use it

[01:59:02.0000] <mkwst>
Ok. It worked! I think.

[01:59:15.0000] <MikeSmith>
mkwst: yeah look in the output dir

[01:59:25.0000] <MikeSmith>
you should have an output dir with everything

[02:00:03.0000] <annevk>
Ms2ger: or wattsi

[02:00:37.0000] <MikeSmith>
as far as speed, wattsi is extremely fast

[02:01:08.0000] <MikeSmith>
I can run a rebuild of the spec in just 8 seconds on my machine

[02:01:34.0000] <mkwst>
MikeSmith,annevk: I think the latest patch fixes the things you've noted.

[02:01:35.0000] <MikeSmith>
the code is actually pretty nice as well

[02:01:48.0000] <MikeSmith>
/me pulls

[02:04:21.0000] <MikeSmith>
annevk: btw before I forget http://stackoverflow.com/tags/fetch-api/info

[02:05:44.0000] <MikeSmith>
mkwst: so I tried twice and I'm still getting Error: missing <dfn> for topic "reflected-xss" explicitly from <code> element containing "reflected-xss"; previous heading contents are "4.2.5.3 Pragma directives"

[02:05:53.0000] <MikeSmith>
and 3 more

[02:06:35.0000] <MikeSmith>
and I still see <code>reflected-xss</code> in my source

[02:06:55.0000] <MikeSmith>
and I'm pretty sure I did actually merge

[02:07:29.0000] <mkwst>
MikeSmith: Yup. I missed reflected-xss. :/ Sorry about that.

[02:07:30.0000] <MikeSmith>
I mean, I merged in your latest to my clone of that branch

[02:07:30.0000] <mkwst>
Up now.

[02:08:16.0000] <MikeSmith>
/me does git fetch && git merge origin/pr/93 again

[02:10:06.0000] <MikeSmith>
mkwst: actually I believe the paragraph at line 14575 is what it's reporting those errors for

[02:10:10.0000] <mkwst>
Do I need any exciting flags to make errors appear? Even without that last commit, I only see "Possible incomplete sections", but no errors.

[02:10:17.0000] <MikeSmith>
oh

[02:10:22.0000] <MikeSmith>
that's odd

[02:10:24.0000] <MikeSmith>
oh

[02:10:33.0000] <MikeSmith>
hmm, yeah, I think I know why

[02:10:42.0000] <MikeSmith>
those errors are from wattsi

[02:10:54.0000] <MikeSmith>
the other ones you can see are from perl scripts

[02:10:59.0000] <mkwst>
(using the origin/sideshowbarker/redesign-output-input-split branch)

[02:11:03.0000] <MikeSmith>
yeah

[02:11:12.0000] <mkwst>
ok. so what command line are you executing?

[02:11:25.0000] <MikeSmith>
if you're not running wattsi locally you won't see those errors I think

[02:11:27.0000] <annevk>
So server-side wattsi doesn't report the parse errors?

[02:11:33.0000] <annevk>
That seems like a problem

[02:11:37.0000] <MikeSmith>
annevk: apparently it does not

[02:11:47.0000] <MikeSmith>
and yeah if so we need to fix that

[02:11:48.0000] <mkwst>
That seems somewhat critical. :)

[02:11:52.0000] <MikeSmith>
yeah

[02:12:08.0000] <MikeSmith>
but it's fixable

[02:12:46.0000] <annevk>
Installing wattsi is pretty trivial though

[02:12:54.0000] <annevk>
Should be even easier with MikeSmith's fix for OS X

[02:13:01.0000] <annevk>
(if you're running OS X)

[02:13:03.0000] <MikeSmith>
we just send the errors back with the bundle, as a errors.log text file, and we just emit (cat) whatever is in thatc

[02:13:18.0000] <MikeSmith>
yeah it is trivial to build wattsi

[02:13:47.0000] <MikeSmith>
except that you have to build Free Pascal from the unstable development sources first

[02:14:02.0000] <MikeSmith>
but hey that's not a PITA, right?

[02:14:26.0000] <MikeSmith>
and download the Free Pascal sources from FTP first too

[02:14:41.0000] <MikeSmith>
but we all like to do that kind of stuff

[02:14:57.0000] <mkwst>
...

[02:15:31.0000] <MikeSmith>
annevk: so I do notice that those error messages don't report the line numbers, which is also not ideal

[02:15:51.0000] <annevk>
MikeSmith: which error messages?

[02:16:03.0000] <MikeSmith>
mkwst: as far as command-line for the build script invocation, I usually just do ./build.sh --no-update

[02:16:18.0000] <MikeSmith>
the ones I cited here earlier

[02:16:25.0000] <MikeSmith>
Error: missing <dfn> for topic "reflected-xss" explicitly from <code> element containing "reflected-xss"; previous heading contents are "4.2.5.3 Pragma directives"

[02:16:29.0000] <mkwst>
MikeSmith: Right. I understand now that it's just wattsi locally vs wattsi as a service.

[02:16:42.0000] <MikeSmith>
k

[02:16:59.0000] <mkwst>
(and I kinda don't want to build wattsi... :) )

[02:17:44.0000] <MikeSmith>
something must be wrong with you if you're not thrilled about the idea of building wattsi yourself

[02:18:04.0000] <MikeSmith>
but, to each his own, as my chauffeur always says

[02:18:25.0000] <MikeSmith>
/me is loopy from lack of sleep and can be safely ignored

[02:19:34.0000] <MikeSmith>
seriously thanks for being the pioneer on using this gear, and for being patient

[02:20:17.0000] <MikeSmith>
we will soon have something that could be GAed for wide use

[02:22:07.0000] <mkwst>
No worries. Thanks for answering my stupid questions. :)

[02:23:46.0000] <annevk>
mkwst: so basically, for CSP and Mixed Content et al, do we want "requesting client" and "target browsing context"?

[02:24:42.0000] <mkwst>
annevk: Yeah, I think that's a reasonable way to name things, and it matches the kinds of checks that I think we actually want to be doing.

[02:47:15.0000] <MikeSmith>
mkwst: pulled and error-free now

[02:47:28.0000] <mkwst>
Huzzah!

[02:47:33.0000] <MikeSmith>
/me turns back to reading the actual content

[02:48:01.0000] <mkwst>
Bah. Form is all that matters!

[02:53:43.0000] <MikeSmith>
mkwst: reviewed and LGTM as far as resolving the review comments I made

[02:54:06.0000] <MikeSmith>
annevk: you're reviewing the changes?

[02:54:45.0000] <mkwst>
Cool. Once annevk is happy, I'll squash. *shrug* No rush. I'd prefer annevk make the Fetch changes so I can make MIX make sense.

[02:54:47.0000] <mkwst>
:)

[03:05:19.0000] <annevk>
mkwst: shouldn't "frame-ancestors directive</dfn>" be "<code>frame-..."?

[03:05:45.0000] <annevk>
<dfn><code>frame-ancestors</code> directive</dfn>

[03:14:14.0000] <annevk>
mkwst: so I go add target browsing context and I notice Fetch has a note on client being null for navigation...

[03:14:19.0000] <annevk>
mkwst: ugh navigation

[03:16:29.0000] <annevk>
I wonder if JakeA is around

[03:16:38.0000] <JakeA>
Yep!

[03:16:41.0000] <JakeA>
Ish

[03:17:13.0000] <annevk>
JakeA: so there's a problem with "client" of sorts in that it doesn't do the right thing for referrer and such

[03:17:19.0000] <annevk>
JakeA: in navigating scenarios

[03:17:45.0000] <annevk>
JakeA: in particular things like <a target=name href=...>x</a> <iframe name=name></iframe>

[03:18:09.0000] <annevk>
JakeA: for this CSP would want the global of <a> as client, SW currently expects null?

[03:18:27.0000] <annevk>
JakeA: is it problematic if we change that around?

[03:22:14.0000] <JakeA>
annevk: the change sounds fair to me

[03:22:51.0000] <JakeA>
wait - is this a security leak?

[03:23:44.0000] <JakeA>
If origin A contains <a href="//B"> and doesn't want to send referrer, B's serviceworker could look at the client and get the full url of the page

[03:24:34.0000] <JakeA>
Feels like the client should be null, to script at least

[03:24:49.0000] <JakeA>
Or, perhaps only in cross-origin cases

[03:30:42.0000] <mkwst>
I'd agree that we shouldn't expose a cross-origin client to script.

[03:30:50.0000] <mkwst>
That would be bad in a number of ways.

[03:31:34.0000] <JakeA>
"Client is null if it's from another origin" seems like a reasonable rule

[03:32:46.0000] <mkwst>
But that makes it difficult to do things like blocking navigation based on `child-src`, or upgrading requests based on the navigator's 'upgrade-insecure-requests' directive, or etc.

[03:33:11.0000] <mkwst>
We need the "requesting client", but there are times where we probably shouldn't expose it to script.

[03:33:31.0000] <JakeA>
Yeah, when I said "Client is null if it's from another origin" I mean script-facing

[03:33:58.0000] <JakeA>
Happy for it to be exposed in spec land

[03:54:38.0000] <mkwst>
annevk: Regarding churn, you could at least use local linking text of "requesting client" in Fetch itself.

[03:55:45.0000] <renlinx>
hi

[03:56:28.0000] <annevk>
mkwst: that would make it request's requesting client

[03:56:45.0000] <annevk>
mkwst: given that you typically prefix usage by request, it might not actually be needed

[03:57:35.0000] <mkwst>
*shrug* As long as "`request`'s `client`" can never be the place where the content is being delivered, and is always the initiator, that's fine.

[04:01:20.0000] <annevk>
mkwst: it's fine that it can go away though right?

[04:01:34.0000] <annevk>
mkwst: e.g., when a browsing context navigates itself

[04:01:43.0000] <mkwst>
Go away?

[04:02:10.0000] <annevk>
mkwst: a browsing context's associated global is typically destroyed in some fashion when navigation takes place

[04:03:06.0000] <mkwst>
Right. I'd hope that would happen after policy checks?

[04:03:21.0000] <annevk>
I hope so

[04:03:40.0000] <mkwst>
Then the spec can hope so too?

[04:03:57.0000] <annevk>
Navigate is not written in terms of Fetch yet

[04:04:05.0000] <annevk>
But yeah, that should be the case

[06:20:44.0000] <MikeSmith>
botie, seen othermaciej

[06:21:07.0000] <MikeSmith>
botie, seen othermaciej?

[06:39:30.0000] <zcorpan>
annevk: pls see https://github.com/whatwg/web-apps-tracker/pull/2 (i don't have mod_python locally so i haven't actually tested it)

[07:55:49.0000] <annevk>
zcorpan: oh cool

[07:59:59.0000] <zcorpan>
/me gotta go

[08:11:23.0000] <annevk>
seems to work with some tweaks

[08:11:33.0000] <jochen__>
annevk: who are you waiting for on https://github.com/whatwg/fetch/issues/80#issuecomment-132474557 ?

[08:34:57.0000] <annevk>
jochen__: nobody really, I fixed the issue

[08:35:04.0000] <annevk>
jochen__: I just don't know how stable it is :-)

[08:35:37.0000] <annevk>
jochen__: I would be okay with Chrome shipping though, personally

[09:18:05.0000] <annevk>
I created https://github.com/whatwg/misc-server for those that have been asking about hosting more miscellaneous server resources

[09:18:15.0000] <annevk>
It's not exactly complete, but it's a start

[09:18:39.0000] <annevk>
(It's a rename of the old web-apps-tracker repository, which we don't really need anymore.)

[09:32:02.0000] <annevk>
mkwst: is your CSP PR waiting on me?

[09:34:52.0000] <annevk>
/me leaves a comment

[09:46:35.0000] <zcorpan>
annevk: nice

[15:52:39.0000] <MikeSmith>
gsnedders: did you ever get a response to https://bugs.launchpad.net/lxml/+bug/1191545/comments/2

[15:57:49.0000] <MikeSmith>
gsnedders: the lxml sources are at https://github.com/lxml/lxml so maybe you could submit a patch

[16:24:37.0000] <MikeSmith>
gsnedders: nm I just did https://github.com/lxml/lxml/pull/174

[16:28:06.0000] <MikeSmith>
hmm, so that change doesn't actually break any of the existing lxml tests

[16:28:08.0000] <MikeSmith>
https://travis-ci.org/lxml/lxml/builds/79199872

[16:29:18.0000] <MikeSmith>
I would have thought its test suite would have a test that this would regress

[16:30:52.0000] <MikeSmith>
maybe it actually doesn't have any tests for the html5parser at all  https://travis-ci.org/lxml/lxml/jobs/79199874

[16:32:33.0000] <MikeSmith>
seems maybe it does not https://github.com/lxml/lxml/tree/master/src/lxml/tests

[16:32:44.0000] <gsnedders>
MikeSmith: I don't care, really. I was just throwing out my opinion why the "bug" is in lxml

[16:36:16.0000] <MikeSmith>
gsnedders: please care :)

[16:36:25.0000] <MikeSmith>
there are a lot of lxml users

[16:36:42.0000] <MikeSmith>
and this causes a lot of them to be confused

[16:38:22.0000] <MikeSmith>
plus, it would be nice if more users used lxml's html5parser rather that the default ad-hoc one


2015-09-08
[21:16:42.0000] <Domenic>
annevk or anyone: is HTMLCollection ever static?

[22:19:42.0000] <annevk>
Domenic: don't think so

[00:17:17.0000] <jochen__>
annevk: k

[01:09:13.0000] <schalkneethling>
morning

[01:10:43.0000] <schalkneethling>
I sent out a mail to the help@whatwg mailing list yesterday about the crossorigin attribute of the video element and so far have not received any helpful comments. Is there someone around that might be able to assist?

[01:11:13.0000] <schalkneethling>
I am curious about the value for this attribute and what restrictions that apply to CORS request

[01:13:33.0000] <schalkneethling>
here is the mail I sent for reference

[01:13:34.0000] <schalkneethling>
https://sneethling.pastebin.mozilla.org/8845530

[01:46:28.0000] <annevk>
schalkneethling: it's a bit complicated due to https://github.com/whatwg/html/issues/95 not being done

[01:46:48.0000] <annevk>
schalkneethling: but effectively anonymous maps to only sending credentials for same-origin fetches

[01:47:05.0000] <annevk>
schalkneethling: and use-credentials means sending credentials for cross-origin fetches too

[01:47:30.0000] <schalkneethling>
thanks annevk and these credentials are sen via HTTP headers?

[01:47:51.0000] <annevk>
schalkneethling: and credentials means cookie headers and some more complicated stuff at the TLS layer

[01:48:27.0000] <annevk>
https://fetch.spec.whatwg.org/#http-network-fetch has most of the details

[01:48:30.0000] <schalkneethling>
thanks a lot annevk, much appreciated

[02:08:33.0000] <MikeSmith>
Domenic: thanks for the latest build-script review--

[02:08:45.0000] <MikeSmith>
caught some good stuff

[02:10:13.0000] <MikeSmith>
w00t the CSP landeth

[02:20:54.0000] <MikeSmith>
fyi beverloo: http://stackoverflow.com/questions/32452581/html5-web-notification-icon-image-not-shown-if-more-notifications-will-be-creat

[02:50:47.0000] <schalkneethling>
what exactly are these credentials that are passed? I know you mentioned cookie headers, but what other credentials does this include?

[02:51:11.0000] <schalkneethling>
I reckon I am trying to understand the use case for using this attribute on a video element for example.

[02:51:15.0000] <schalkneethling>
annevk: ^^

[02:51:36.0000] <annevk>
schalkneethling: see the link I gave

[02:52:00.0000] <annevk>
schalkneethling: you might use it if the video you show depends on whether or not the user is logged in

[02:52:20.0000] <annevk>
schalkneethling: e.g., you show a personalized video if the user is logged in, and a generic one if not

[02:53:17.0000] <schalkneethling>
ah! and so, anonymous will send those credentials for same origin request but not cross origin whereas use-credentials will send it for both

[02:53:51.0000] <annevk>
yes

[02:53:58.0000] <annevk>
anonymous is misnamed

[02:54:21.0000] <schalkneethling>
so essentially if you are loading video from a third party service, and that service required login credentials to determine whether you have access to the video or not, you would need to set crossorigin=use-credentials

[02:55:03.0000] <schalkneethling>
yeah, anonymous seems to imply no credentials at all.

[02:55:15.0000] <schalkneethling>
but I get it now I believe ;) Thanks again annevk

[03:29:02.0000] <nox>
annevk: Did you see my second adopting steps PR btw?

[03:44:28.0000] <beverloo>
MikeSmith, ty! +1 to your question, no idea what he means either, but I'll test around

[03:44:39.0000] <beverloo>
MikeSmith, fwiw, we're going to automatically dismiss Web Notifications starting Chrome 47

[03:44:47.0000] <smaug____>
"Developers can set the argument r with either a promise that resolves with a Reponse object or a Reponse " I doubt "Reponse" is right there

[03:45:03.0000] <smaug____>
4.5.4 in SW draft

[03:45:08.0000] <MikeSmith>
beverloo: ah cool

[03:45:17.0000] <smaug____>
^ whoever is editing SW these days

[03:58:55.0000] <nox>
gsnedders: No idea if you even care, but <template> landed in Servo. o//

[04:55:48.0000] <MikeSmith>
https://bugs.webkit.org/show_bug.cgi?id=146336 "Chrome 43 decides that allowing the website to pollute your clipboard inside _any_ DOM event handler is no longer a concern" 😄

[05:04:54.0000] <mkwst>
annevk: re: fetch and referrer, how is Fetch going to work with the concern yoav raises in https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0043.html?

[06:04:38.0000] <gsnedders>
nox: congrats!

[06:17:06.0000] <gsnedders>
jgraham: why did you stop caring about linear history for html5lib?

[06:22:11.0000] <jgraham>
gsnedders: "I forgot"

[06:31:37.0000] <nox>
Why would one care for linear history at all?

[06:34:36.0000] <Ms2ger>
Because it's much easier to figure out what happened

[06:35:59.0000] <gsnedders>
And in what order.

[06:43:45.0000] <nox>
How is "things happened at the merge" different from "things happened at the commit"?

[06:47:08.0000] <wanderview>
Domenic: can you help me understand what changed in https://github.com/whatwg/streams/pull/385 that deviates from our july discussion at mozilla?

[06:48:06.0000] <wanderview>
Domenic: is it just that we don't automatically unlock/release the reader when the end of the stream is reached?

[06:48:29.0000] <wanderview>
to avoid code using ReadableStreamReader() after its been unlocked

[06:49:22.0000] <annevk>
nox: yeah did, when I saw it initially I thought it should maybe be done differently, but I guess it's okay

[06:49:49.0000] <nox>
annevk: Wouldn't it be better to be safe now, and maybe revert it back later?

[06:49:49.0000] <annevk>
mkwst: Fetch already works fine with cross-origin stylesheets, that's why we allow cross-origin referrers for "passthrough requests"

[06:50:34.0000] <mkwst>
annevk: I was thinking about the client. That is, how do we know that the stylesheet is requesting the resource so that we can use its URL as the referrer.

[06:50:57.0000] <annevk>
mkwst: oh well CSS needs to set the URL correctly

[06:51:28.0000] <annevk>
mkwst: that's why referrer can be a URL

[06:51:28.0000] <mkwst>
annevk: I see. So, TabAtkins? :)

[06:51:37.0000] <annevk>
Yeah

[06:51:59.0000] <mkwst>
Where does one file bugs against whatever CSS spec I'd need to file a bug against?

[06:53:12.0000] <annevk>
I don't know

[06:56:24.0000] <Ms2ger>
www-style

[06:57:18.0000] <mkwst>
Ms2ger: That's not a bug tracker? :)

[06:57:40.0000] <astearns>
and yet it's the currently correct answer

[06:58:04.0000] <Ms2ger>
What makes you think you'd get a sensible process out of the csswg?

[07:11:29.0000] <nox>
It is that bad?

[07:11:44.0000] <nox>
Ms2ger: annevk says the one loop for adopting steps is fine.

[07:12:06.0000] <annevk>
nox: no that's not what I meant

[07:12:08.0000] <nox>
Disregard that, fix just got merged.

[07:12:10.0000] <Ms2ger>
Ha

[07:12:16.0000] <nox>
annevk: Yeah, I realise that now. :)

[07:12:36.0000] <annevk>
nox: although it might be... I haven't really figured out any bad effects yet

[07:12:51.0000] <nox>
With just img and template, can't think of one.

[07:12:58.0000] <annevk>
nox: I mostly meant that I thought the language should maybe be different, more like how it was originally, but decided against asking for that

[07:13:35.0000] <Ms2ger>
I agree it's probably fine now

[07:14:12.0000] <TabAtkins>
mkwst: Yeah, www-style is currently still the correct answer. Houdini switched to GH issues, and we're using it as a trial run to convince the rest of the group to make CSS the same.

[07:14:43.0000] <Ms2ger>
But I don't like running random code while one of my invariants is broken

[07:17:04.0000] <annevk>
Ms2ger: yeah, even with an adopt callback it would still not be problematic, but would be even more confusing and you'd have to know the callback runs as a nanotask, etc.

[07:17:30.0000] <annevk>
Ms2ger: seems better indeed to preserve invariants and allow implementations to optimize as they see fit

[07:17:52.0000] <annevk>
TabAtkins: there's also a whole bunch of Bugzilla components that Hixie and I used to file bugs in

[07:18:08.0000] <annevk>
TabAtkins: that sometimes get attention, but not as often as I'd like

[07:18:12.0000] <TabAtkins>
Right, which I need to trawl through and close out.

[07:19:11.0000] <annevk>
https://www.webkit.org/blog/3996/introducing-the-rendering-frames-timeline/ looks pretty interesting

[07:30:33.0000] <mkwst>
When is the WHATWG going to publish important work like http://www.w3.org/blog/news/archives/4965?

[08:43:55.0000] <nox>
gsnedders: I think there is a test that is wrong in html5lib-tests as per https://github.com/whatwg/html/pull/101.

[08:44:23.0000] <nox>
With "<html><ruby>a<rtc>b<rp></ruby></html>" the expectation in the tests is that the <rp> is the following sibling of <rtc>.

[08:45:03.0000] <nox>
But https://github.com/whatwg/html/pull/101/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebR105566 says no implied end tag should be generated for <rtc>.

[09:06:29.0000] <annevk>
nox: in Chrome and Firefox <rp> ends up as a child, too

[09:06:44.0000] <nox>
annevk: In Safari it's the next sibling, but I guess we should shrug that.

[09:07:38.0000] <annevk>
nox: oh really? I wonder how that happened since Chrome copied their impl

[09:08:20.0000] <nox>
annevk: I'm not on latest OS X so I'm not sure I've got latest Safari.

[09:09:01.0000] <annevk>
Oh yeah, the logic WebKit landed is a little different

[09:09:04.0000] <annevk>
http://trac.webkit.org/changeset/167437/trunk/Source/WebCore/html/parser/HTMLTreeBuilder.cpp

[09:09:18.0000] <annevk>
I emailed some of the WebKit folks, but they didn't get back to me

[09:11:27.0000] <nox>
annevk: Sounds like déjà-vu.

[09:11:57.0000] <annevk>
nox: yeah, it's a bit harder to get in touch with them :-/

[09:14:35.0000] <annevk>
nox: so html5lib-tests ended up with the wrong test somehow too?

[09:16:17.0000] <nox>
annevk: Yes.

[09:16:26.0000] <nox>
annevk: Expects <rtc></rtc><rb>…

[09:16:31.0000] <nox>
s/rb/rp/

[09:23:19.0000] <annevk>
https://github.com/whatwg/html/pull/101#issuecomment-138619166

[09:26:02.0000] <annevk>
When W3C forks, you've got three problems

[09:26:06.0000] <nox>
https://github.com/whatwg/html/pull/101#issuecomment-138621430

[09:26:12.0000] <nox>
annevk: Hopefully it's a bug.

[09:26:22.0000] <nox>
At best it's a bug,

[09:26:28.0000] <Domenic>
annevk: I am at a computer with Edge now. Give me a live-dom-viewer test case?

[09:26:28.0000] <nox>
at worst it's undocumented crap.

[09:26:50.0000] <annevk>
Domenic: <rtc><script>w(getComputedStyle(document.querySelector("rtc")).display)</script>

[09:27:17.0000] <Domenic>
annevk: inline

[09:27:19.0000] <annevk>
Domenic: <ruby><rtc><rp>

[09:27:20.0000] <Domenic>
annevk: what about parser?

[09:27:35.0000] <Domenic>
annevk: ruby -> rtc -> rp

[09:27:51.0000] <annevk>
Domenic: <ruby><rt><rtc>

[09:28:09.0000] <Domenic>
annevk: ruby -> rt -> rtc

[09:28:14.0000] <annevk>
Domenic: <ruby><rp><rtc>

[09:28:25.0000] <Domenic>
annevk: ruby -> rp -> rtc

[09:28:26.0000] <annevk>
Domenic: seems like they haven't implemented HTML51

[09:28:30.0000] <Domenic>
Yeah

[09:28:38.0000] <Domenic>
That is kind of what Travis's message implied but it wasn't 100% clear

[09:28:39.0000] <annevk>
Domenic: rtc shouldn't be a child in those scenarios

[09:29:02.0000] <annevk>
Domenic: yeah, not changing in forever sounded like they still support some really old stuff

[09:29:16.0000] <annevk>
Domenic: <ruby><rb><rt>

[09:29:33.0000] <Domenic>
annevk: ruby -> rb -> rt

[09:30:17.0000] <annevk>
Domenic: that sure looks like the pre-fork behavior, though I'm not a 100% what the old-IE behavior was

[09:30:24.0000] <Domenic>
yeah

[09:30:35.0000] <Domenic>
now we have what, three parsing behaviors and two style behaviors?

[09:30:48.0000] <annevk>
Domenic: three style behaviors if you count HTML51

[09:31:00.0000] <annevk>
Domenic: Mozilla didn't actually implement the spec

[09:31:07.0000] <Domenic>
good times

[09:31:16.0000] <annevk>
Domenic: or maybe Mozilla's feedback never got addressed, I didn't bother to find out

[09:31:32.0000] <annevk>
Domenic: my style commit is for the Mozilla behavior

[09:31:58.0000] <Domenic>
I tend to agree with your latest plan of parsing changes only, no styling. But we should ping the browser people.

[09:32:16.0000] <Domenic>
I will write up a reply with @-mentions

[09:32:50.0000] <annevk>
thanks

[09:36:15.0000] <nox>
Will fix html5lib-tests.

[09:37:49.0000] <annevk>
nox: cool

[09:38:01.0000] <annevk>
nox: I'm somewhat curious how html5lib-tests ended up with the wrong tests

[09:38:05.0000] <annevk>
nox: I wonder if gsnedders knows

[09:38:05.0000] <nox>
annevk: I'm at 3 PRs already for this thing, one less or more…

[09:38:11.0000] <annevk>
nox: ugh

[09:38:19.0000] <nox>
Well, one was because I can't alphabet.

[09:38:35.0000] <nox>
And bot decided to go YOLO on me.

[09:38:43.0000] <annevk>
nox: darobin who made the HTML51 fork also contributed a patch to html5lib-tests

[09:38:45.0000] <nox>
https://github.com/servo/string-cache/pull/108 > https://github.com/servo/string-cache/pull/109

[09:38:53.0000] <annevk>
nox: so I wonder if he got that patch wrong

[09:39:10.0000] <annevk>
nox: his html5lib-python impl was also wrong

[09:39:18.0000] <nox>
annevk: Oh wait,

[09:39:22.0000] <annevk>
nox: perhaps they decided on a change in parsing behavior and never let html5lib or WebKit know

[09:39:27.0000] <nox>
annevk: I think our tests are just outdated in html5ever.

[09:39:44.0000] <nox>
annevk: That patch seems to fix the test I said was wrong.

[09:40:19.0000] <annevk>
nox: https://github.com/html5lib/html5lib-tests/pull/27/files#diff-31f05185c1fa91686be8bf73cd5cd0bbR142

[09:41:02.0000] <nox>
annevk: https://github.com/html5lib/html5lib-tests/pull/55/files

[09:41:10.0000] <annevk>
nox: so somewhere between December 2013 and WebKit's implementation, some change in behavior was decided upon

[09:41:55.0000] <nox>
annevk: Yes, in #54 and #55.

[09:43:06.0000] <annevk>
nox: as far as that test goes, sure (that only a single test need to be changed is somewhat worrying)

[09:43:13.0000] <annevk>
nox: but what about the specification?

[09:43:29.0000] <nox>
annevk: What do you mean?

[09:44:17.0000] <annevk>
nox: I mean that I think that on Dec 13 the specification prescribed the WebKit behavior and that on Feb 14 it no longer did, or some such, based on some feedback

[09:46:40.0000] <annevk>
nox: https://github.com/w3c/html/commit/e2ddb663fd04803d2be7f16026e2117ced167c01#diff-36cd38f49b9afa08222c0dc9ebfe35ebR100710

[09:47:53.0000] <nox>
annevk: Oh! You're right.

[09:48:00.0000] <wanderview>
It seems JakeA grew a mustache... https://www.youtube.com/watch?v=tilH8jgLrXQ

[09:48:01.0000] <nox>
Not a bug in WebKit then, damn. :(

[09:48:18.0000] <annevk>
nox: well it's a bug in WebKit today, of sorts

[09:48:29.0000] <annevk>
nox: since the current spec says something else

[09:48:38.0000] <nox>
I mean, it didn't come into existence as a bug.

[09:48:43.0000] <nox>
That would be the best.

[09:48:55.0000] <annevk>
Nothing on the mailing list that suggests why they changed the specification though

[09:51:01.0000] <nox>
annevk: "New ruby model"

[09:51:04.0000] <nox>
Sounds clear.

[09:51:18.0000] <annevk>
?

[09:51:59.0000] <nox>
annevk: Sarcasm.

[09:52:12.0000] <MikeSmith>
who was the WebKit reviewer for ththat patch?

[09:52:37.0000] <annevk>
Well, that Dec 13 email is somewhat clear, it's just that there's no email that explains they changed the parser again after making that change and after WebKit implemented the original text...

[09:52:50.0000] <annevk>
And tests against the original text landed in Python, etc.

[09:53:18.0000] <annevk>
The original text also didn't account properly for end-of-file behavior for fragment cases

[09:53:26.0000] <nox>
https://github.com/Igalia/webkit/commit/135c1f2d74a05733c5a0421745bc4e050db95d18?

[09:53:33.0000] <annevk>
MikeSmith: Darin

[09:54:23.0000] <annevk>
nox: hmm yeah, did that never land in WebKit or never make it into Safari?

[09:54:49.0000] <nox>
annevk: What do you mean? From what I read that's the wrong behaviour that I'm seeing in Safari.

[09:54:54.0000] <nox>
No?

[09:55:05.0000] <nox>
Cf. https://github.com/Igalia/webkit/commit/135c1f2d74a05733c5a0421745bc4e050db95d18#diff-bf6ceb92999573c891184de559e34448R196

[09:55:44.0000] <annevk>
nox: sorry, I thought that was a follow up commit

[09:55:57.0000] <nox>
annevk: No problem.

[09:57:32.0000] <annevk>
So it seems like "HTML5" has a different parsing model from "HTML51"

[09:57:48.0000] <annevk>
And WebKit implements the former and Chromium and Gecko implement the latter

[09:57:57.0000] <annevk>
And Edge implements WHATWG HTML

[09:58:21.0000] <annevk>
That is, even http://www.w3.org/TR/2014/REC-html5-20141028/ has the "broken" parsing rules

[10:00:37.0000] <Domenic>
annevk, is this correct? is there a better description for (2)? https://www.irccloud.com/pastebin/HjhsQfdi/

[10:00:59.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25212 hints of change too, but darobin didn't provide pointers

[10:02:06.0000] <annevk>
Domenic: yeah I think so, there's a couple other parsing differences most likely, but this is a good summary

[10:05:44.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26074 is another bug but not this one

[10:07:13.0000] <gsnedders>
annevk: It's been a long time since people did in-depth reviews for tests where we already have interop on, and the Ruby stuff was done mostly on trust on the basis that implementors will find the bugs

[10:07:27.0000] <gsnedders>
annevk: esp. given it seemed likely the spec would change after they landed

[10:08:48.0000] <annevk>
I can't find the root cause of HTML51 changing the parsing rules yet again :-(

[10:11:29.0000] <annevk>
And https://www.w3.org/Bugs/Public/show_bug.cgi?id=26074#c3 suggests WebKit implemented from the content model descriptions rather than the tree construction algorithm?!

[10:12:36.0000] <gsnedders>
?!

[10:15:38.0000] <annevk>
Domenic: is Koji with Blink?

[10:15:50.0000] <annevk>
Domenic: I thought he might be independent

[10:16:24.0000] <Domenic>
annevk: no he's a Googler on Blink.

[10:16:29.0000] <annevk>
okay

[10:18:19.0000] <nox>
https://github.com/darobin/html-ruby/commit/94fd27f9fabf7613b7eee30b02d9b73bae99ecc9

[10:18:38.0000] <annevk>
Domenic: it does seem like we should only make changes here once everyone or at least 3/4th agrees

[10:18:54.0000] <nox>
https://github.com/darobin/html-ruby/commit/ccf81bb51941d6e630b94a69626e6b96ce9d62fc Seems like it comes from this.

[10:19:01.0000] <Domenic>
annevk: yeah, that is my leaning as well.

[10:19:05.0000] <nox>
As in, if it's for fallback content, it should probably not end up in rtc.

[10:19:35.0000] <gsnedders>
nox: does html5ever have any test CLI interface reading a file/stdin and dumping some debug tree out?

[10:19:45.0000] <nox>
https://lists.w3.org/Archives/Public/www-archive/2013Sep/0058.html

[10:19:50.0000] <nox>
annevk, Domenic:

[10:19:56.0000] <nox>
Seems to be the one thread that matters.

[10:20:12.0000] <nox>
gsnedders: Yes, kinda.

[10:20:24.0000] <annevk>
nox: it can't be that because that is before anything landed in HTML5

[10:20:28.0000] <nox>
gsnedders: The tool that produces the same output as html5lib-tests is unexposed though.

[10:21:56.0000] <nox>
annevk: Oh right. Well the only thing I can find is https://github.com/darobin/html-ruby/commit/94fd27f9fabf7613b7eee30b02d9b73bae99ecc9 then.

[10:23:19.0000] <ccardona-work>
Good morning/afternoon/evening WHATWG crew o/

[10:27:42.0000] <gsnedders>
nox: /win 26

[10:27:45.0000] <gsnedders>
um, uh

[10:27:48.0000] <gsnedders>
that doesn't work

[10:28:38.0000] <jgraham>
Trying to get rid of nox, indeed

[10:29:17.0000] <nox>
lol

[10:33:55.0000] <gsnedders>
nox: so is there any reasonable way to test it? :P

[10:34:39.0000] <nox>
gsnedders: Will look into it once I get home, but otherwise you can just write a tree_builder test and run html5ever's tests.

[10:35:03.0000] <gsnedders>
right, k

[11:01:07.0000] <wanderview>
JakeA: are you around still?

[11:05:10.0000] <nox>
gsnedders: What did you want to test btw?

[11:19:26.0000] <gsnedders>
nox: https://critic.hoppipolla.co.uk/showcomment?chain=12351

[11:20:02.0000] <nox>
gsnedders: You evil person.

[11:20:26.0000] <gsnedders>
nox: not my test!

[11:20:28.0000] <gsnedders>
/me hides

[11:20:31.0000] <nox>
Ah ah.

[11:21:38.0000] <nox>
gsnedders: https://gist.github.com/nox/44f289320e3a57dac0de

[11:21:41.0000] <nox>
Fail.

[11:22:17.0000] <nox>
<em> in <aside> missing.

[11:23:14.0000] <nox>
gsnedders: Oh right,

[11:23:24.0000] <nox>
gsnedders: as long as it only involve the HTML namespace,

[11:23:34.0000] <nox>
gsnedders: You can do echo '…' | target/debug/examples/print-rcdom

[11:24:06.0000] <nox>
https://gist.github.com/nox/123af37323ff5c329336

[11:26:59.0000] <nox>
gsnedders: Did we get active formatting markers or whatever wrong?

[11:27:02.0000] <nox>
Or is the test wrong?

[11:28:30.0000] <gsnedders>
nox: I think the test is wrong

[11:28:35.0000] <nox>
gsnedders: Good.

[11:28:37.0000] <gsnedders>
nox: it's from Blink and AFAICT only Blink pass

[11:28:46.0000] <gsnedders>
nox: But I haven't sat down to check what the spec says

[11:28:52.0000] <gsnedders>
nox: Because hand executing the AAA, ewww

[11:29:04.0000] <nox>
You know,

[11:29:11.0000] <nox>
when you say AAA,

[11:29:38.0000] <nox>
I read this as AAAAA,

[11:29:55.0000] <nox>
which designate the best kind of https://en.wikipedia.org/wiki/Andouillette.

[11:30:19.0000] <nox>
Which is better than AAA, for sure.

[11:41:05.0000] <nox>
gsnedders: Doesn't look like <em> is popped off the stack of active formatting elements.

[11:41:21.0000] <nox>
But "If the last (most recently added) entry in the list of active formatting elements is a marker, or if it is an element that is in the stack of open elements, then there is nothing to reconstruct; stop this algorithm."

[11:48:51.0000] <nox>
gsnedders: Try this:

[11:49:05.0000] <nox>
<b><em><foo><aside></b></em>

[11:49:08.0000] <nox>
<b><em><foo><foo><aside></b></em>

[11:49:12.0000] <nox>
<b><em><foo><foo><foo><aside></b></em>

[12:04:50.0000] <mkwst>
annevk: did you work out the null client for navigation thing?

[12:05:20.0000] <mkwst>
annevk: If the properties in Fetch are solid, I'll update MIX. If things are still in flux, I'll hold off a bit.

[12:18:50.0000] <mkwst>
annevk: Eh. It looks solid enough. :) Hopefully https://github.com/w3c/webappsec/commit/05c7c4caf52596baab0acb85083be3a1dd710ae2 makes sense.

[13:50:52.0000] <gsnedders>
nox: yeah, I've noticed this already.

[13:51:00.0000] <gsnedders>
nox: it's just working out what is right :P

[13:54:11.0000] <gsnedders>
nox: Edge seems to match WebKit/Blink here, blargh

[13:55:10.0000] <nox>
gsnedders: Looks weird that the em suddenly disappears when there are three foos.

[14:00:10.0000] <gsnedders>
nox: yes, but this is expected to avoid O(n^2) behaviour

[14:02:09.0000] <nox>
gsnedders: Oh ok.

[15:59:14.0000] <nox>
In HTML5, isn't the insertion point always either undefined or after the last consumed character that was fed into the input stream at that script nesting level?

[16:26:45.0000] <nox>
https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-write I don't understand the part about script end tag in step 7. :(

[16:29:13.0000] <gsnedders>
nox: <script>document.write("</" + "script>");</script> is such a case, no?

[16:29:41.0000] <nox>
gsnedders: I think so. What is it supposed to do?

[16:32:06.0000] <gsnedders>
um, it doesn't do what I thought

[16:32:53.0000] <nox>
gsnedders: What was your intuition? To see if it's the same as mine.

[16:33:42.0000] <gsnedders>
<script>document.write("</" + "script>xxx");</script>

[16:33:45.0000] <gsnedders>
what happens to the xxx?

[16:34:45.0000] <nox>
Yeah.

[16:35:16.0000] <nox>
1<script>document.write('2<','script><','/script>3');document.write('4<','script><','/script>5');</script>6

[16:35:35.0000] <nox>
Err,

[16:35:42.0000] <nox>
1<script>document.write('2<','/script>3');document.write('4<','/script>5');</script>6

[16:36:13.0000] <nox>
I expected 124356, or 124536.

[16:36:30.0000] <nox>
I got 123456, so I don't understand the bits about </script>.

[16:36:45.0000] <gsnedders>
It's been years since I've touched this much though :)

[16:39:13.0000] <nox>
To me, it sounds like all arguments should be written in the input buffer, but some are processed at call-time, and some when the parser resumes.


2015-09-09
[18:55:27.0000] <MikeSmith>
does anybody happen to now if IE/Edge supports new XPathEvaluator() ?

[18:57:12.0000] <MikeSmith>
hmm a search seems to indicate it's not in IE 11 at least, so I guess not in Edge either

[19:33:57.0000] <deltab>
MikeSmith: Edge but not IE: https://dev.modern.ie/platform/status/domlevel3xpath/?filter=f3f0000bf&search=xpath

[19:48:54.0000] <MikeSmith>
deltab: oh, thanks

[19:48:59.0000] <MikeSmith>
/me looks

[19:49:29.0000] <MikeSmith>
nice

[19:50:09.0000] <MikeSmith>
Domenic: https://github.com/YuzuJS/setImmediate/commit/ab4d23262270222aace074ca526b311f094ac27b is excellent

[19:51:33.0000] <Domenic>
Domo!

[20:23:45.0000] <MikeSmith>
Domenic: btw about the HTML build, I don't know if you saw when mkwst and I were chatting here yesterday or so, but there's an issue with error reporting related to using the remote wattsi service vs running wattsi locally.

[20:24:35.0000] <MikeSmith>
Specifically the issue is that if you use the remote service you won't see any errors that wattsi reports.

[20:24:38.0000] <MikeSmith>
Right?

[20:26:29.0000] <MikeSmith>
So yesterday when mkwst was making his changes locally and building, he wasn't seeing some wattsi errors about some markup issues in his changes.

[20:28:16.0000] <MikeSmith>
So anyway, I would guess we can fix it easily just be writing the stderr to a build.log file on the server side, and packaging that up with wattsi output, and then on the local side when we upack that wattsi build, we just have the build script cat that build.log file.

[21:05:13.0000] <MikeSmith>
botie, inform Ms2ger http://logs.glob.uno/?c=mozilla%23mdn#c32485

[21:05:13.0000] <botie>
will do

[23:09:12.0000] <annevk>
mkwst: I need to work through HTML before being 100% sure, working on that, but it's a lot of work

[23:09:47.0000] <mkwst>
Ok.

[23:29:42.0000] <MikeSmith>
gsnedders: FYI https://github.com/lxml/lxml/pull/174#issuecomment-138795020

[23:30:14.0000] <MikeSmith>
annevk: apologies for the giant mess that's been made of the ruby stuff

[23:30:20.0000] <MikeSmith>
I should have done more to stop that

[23:31:25.0000] <MikeSmith>
but fwiw I am in the process of completely exiting from any involvement in that forking business going forward

[23:32:27.0000] <MikeSmith>
I still hope to convince others to just stop doing it, and I'm optimistic that I have a chance of doing that, and good arguments against it (like this ruby case)

[23:33:08.0000] <MikeSmith>
but if I can't convince them to stop it, at least I can choose not to even indirectly faciliate it any longer

[23:33:11.0000] <MikeSmith>
enough is enogh

[23:40:16.0000] <JakeA>
wanderview: sorry, was in a bar without reception, then panic-packing for a trip.

[23:43:26.0000] <botie>
Ms2ger, at 2015-09-09 04:05 UTC, MikeSmith said: http://logs.glob.uno/?c=mozilla%23mdn#c32485

[23:43:37.0000] <Ms2ger>
Yessir

[23:44:00.0000] <Ms2ger>
MikeSmith, "ask an admin", I think

[23:44:02.0000] <MikeSmith>
Ms2ger: happy to talk on #mdn if you have guidance on that

[23:44:04.0000] <MikeSmith>
oh

[23:44:07.0000] <MikeSmith>
thanks!

[23:44:10.0000] <Ms2ger>
Np

[23:44:58.0000] <MikeSmith>
Ms2ger: who's the EU-hours admin? teoli?

[23:45:11.0000] <Ms2ger>
Sounds plausiblr

[23:45:13.0000] <Ms2ger>
ble

[23:45:16.0000] <MikeSmith>
k

[23:47:23.0000] <MikeSmith>
Ms2ger: does mozilla IRC have any message-bot-like thingey that people use? e.g., like botie. Or do people use MsgServ? Or they just wait?

[23:47:45.0000] <MikeSmith>
/me is just wondering what the culture is and doesn't want to step on toes

[23:48:44.0000] <Ms2ger>
fennecbot has that feature

[23:48:56.0000] <MikeSmith>
ah cool

[23:48:59.0000] <Ms2ger>
It's not very widely used, though

[23:49:03.0000] <MikeSmith>
ok

[00:10:51.0000] <annevk>
MikeSmith: thanks, but it's not your fault

[00:34:12.0000] <annevk>
wanderview: did you see https://github.com/whatwg/fetch/pull/119?

[00:34:40.0000] <annevk>
wanderview: if you don't have time to look at it that's fine, but then I'll start merging the Streams stuff in and hope for more review later on

[01:28:32.0000] <annevk>
o_O, http://www.w3.org/TR/xhtml/ redirects to /Markup/

[01:35:03.0000] <Ms2ger>
/me schedules a party on 17 December

[01:42:56.0000] <annevk>
Ms2ger: significance?

[01:43:37.0000] <Ms2ger>
5 years since the XHTML2 WG died

[01:46:42.0000] <annevk>
There must be better reasons to organize parties

[01:57:17.0000] <MikeSmith>
annevk: where should http://www.w3.org/TR/xhtml/ go?

[01:57:57.0000] <MikeSmith>
I can't change what http://www.w3.org/TR/xhtml/ redirects to but I can make https://www.w3.org/MarkUp/ redirect to somewhere useful

[01:58:33.0000] <annevk>
MikeSmith: I dunno, was just trying to find the XHTML specification for a date citation on dev.platform

[01:58:52.0000] <annevk>
MikeSmith: found it by going to /TR/xhtml1/

[01:58:54.0000] <MikeSmith>
annevk: ah I guess you were rightly hoping that http://www.w3.org/TR/xhtml/ would take you to the XHTML spec

[01:58:59.0000] <MikeSmith>
yeah

[01:59:02.0000] <annevk>
MikeSmith: made sense in my mind

[01:59:14.0000] <MikeSmith>
I will make /Markup redirect there

[01:59:38.0000] <annevk>
MikeSmith: wouldn't the /Markup/ folks get upset then about their history?

[01:59:51.0000] <MikeSmith>
dunno maybe

[02:00:15.0000] <MikeSmith>
I guess if they don't it will be an indication that nobody uses that page

[02:00:54.0000] <MikeSmith>
long-term I guess I can ask for http://www.w3.org/TR/xhtml/ to be symlinked to /TR/xhtml1 instead

[02:01:31.0000] <Ms2ger>
MikeSmith, why not to html.s.w.o? :)

[02:13:26.0000] <jgraham>
I guess MikeSmith still likes his job :)

[02:29:02.0000] <nox>
gsnedders: Managed to make sense out of yesterday's test case?

[02:33:12.0000] <schalkneethling>
annevk: so, the crossorigin attribute on the video element. That is not implemented by anyone yet right?

[02:33:34.0000] <annevk>
schalkneethling: I would think it is

[02:34:02.0000] <schalkneethling>
oh, great. I thought because of your comment yesterday and pointer to the issue on Github it might not be

[02:36:18.0000] <annevk>
schalkneethling: that issue is mostly about refactoring

[02:36:27.0000] <schalkneethling>
ah ok, got it

[02:39:24.0000] <MikeSmith>
annevk: fwiw https://www.w3.org/TR/xhtml/ now redirects to the right place (thanks to a haz-root friend on the systeam fast-tracking the update to the symlink)

[02:39:57.0000] <MikeSmith>
and People Who Like https://www.w3.org/MarkUp/ can remain happy

[02:41:15.0000] <Ms2ger>
MikeSmith, righter, at least :)(

[02:43:15.0000] <MikeSmith>
Ms2ger: Progress Not Perfection

[02:43:23.0000] <MikeSmith>
One Day At a Time

[02:43:47.0000] <Ms2ger>
A variant of w3c's slogan, "Process Not Perfection"?

[02:44:20.0000] <MikeSmith>
oh burn

[02:44:52.0000] <MikeSmith>
my wife asking me what I'm laughing about and why I have silly grin on my face

[02:45:06.0000] <MikeSmith>
Ms2ger: that is your best material in a long time

[02:45:15.0000] <MikeSmith>
you should take that one the road

[02:45:38.0000] <MikeSmith>
did you just spontaneously come up with that one right now?

[02:45:45.0000] <Ms2ger>
Eh, the good ones are few and far between :)

[02:45:51.0000] <MikeSmith>
indeed

[02:48:15.0000] <nox>
gsnedders: It's related to the step "If inner loop counter is greater than three and node is in the list of active formatting elements, then remove node from the list of active formatting elements."

[02:48:35.0000] <Ms2ger>
Ah, the "Magic Step"

[02:49:34.0000] <nox>
gsnedders: nox 1 Blink 0

[02:49:38.0000] <nox>
I think I found their bug.

[02:49:47.0000] <Ms2ger>
Just the one?

[02:49:53.0000] <nox>
https://github.com/nwjs/blink/blob/be948afff52a140cdb9339c918e62fc71759904e/Source/core/html/parser/HTMLTreeBuilder.cpp#L1533-L1534

[02:50:01.0000] <nox>
Ms2ger: <b><em><foo><foo><foo><aside></b></em>

[02:50:16.0000] <nox>
Ms2ger: Blink keeps <em> as an active formatting element.

[02:50:21.0000] <nox>
Note how the loop is done,

[02:50:28.0000] <nox>
it increments after the iteration,

[02:50:39.0000] <nox>
while the spec says to increment when before each of them.

[02:50:56.0000] <nox>
Ultimately resulting in off-by-one errors on the iteration limit check.

[02:52:10.0000] <nox>
It's a bit of a PITA that they don't even follow the spec exactly in their code flow.

[02:52:23.0000] <zcorpan>
hmm, looks like the spec doesn't have a name for this magic step

[02:57:28.0000] <nox>
I don't even know why they use the 3 as the iteration limit.

[02:57:32.0000] <nox>
It's not what the spec says. :(

[02:58:01.0000] <nox>
The spec says to do something magical when iteration count is greater than 3, sure, but that's not stopping the loop at 3 iterations.

[02:59:01.0000] <nox>
I also like how it's called "step 9", when in the spec it's "step 13".

[03:03:17.0000] <annevk>
nox: but that's not exactly the latest blink code, is it?

[03:03:27.0000] <nox>
annevk: That's what I'm checking.

[03:04:28.0000] <nox>
annevk: https://chromium.googlesource.com/chromium/blink/+/master/Source/core/html/parser/HTMLTreeBuilder.cpp

[03:04:36.0000] <nox>
Can't link to lines, but it looks the same.

[03:05:08.0000] <nox>
https://chromium.googlesource.com/chromium/blink/+/master/Source/core/html/parser/HTMLTreeBuilder.cpp#1531

[03:17:31.0000] <nox>
https://github.com/html5lib/html5lib-tests/pull/67#issuecomment-138864769

[03:20:53.0000] <schalkneethling>
annevk: if you have a moment I would love your comments on this https://github.com/schalkneethling/exploring-html/blob/master/embedded_content/video.html#L91

[03:20:55.0000] <schalkneethling>
thanks

[03:22:00.0000] <annevk>
schalkneethling: note that you also need to use crossorigin if you want to load cross-origin video and inspect certain metadata

[03:23:01.0000] <schalkneethling>
ah, thought there might be a link there. Are there some docs on this?

[03:23:41.0000] <schalkneethling>
So does the crossorigin attribute on the video element override what is set in the CSP policy? Or is this not related?

[03:24:18.0000] <schalkneethling>
/me trying to think if you can control more than css an js and seem to think you can

[03:25:38.0000] <annevk>
schalkneethling: well, the spec is a doc

[03:25:46.0000] <annevk>
schalkneethling: CSP is not related

[03:26:02.0000] <schalkneethling>
sure, let me have a read over that again

[03:26:45.0000] <zcorpan>
schalkneethling: loop="true" is invalid, should be just loop (or loop="" or loop="loop")

[03:27:19.0000] <zcorpan>
same for muted

[03:27:21.0000] <schalkneethling>
oh, ok. spec suggested value is a boolean?

[03:27:38.0000] <schalkneethling>
http://www.w3.org/TR/html5/embedded-content-0.html#attr-media-loop

[03:27:43.0000] <schalkneethling>
oooooh

[03:27:43.0000] <zcorpan>
schalkneethling: no, it says it's a "boolean attribute"

[03:27:48.0000] <schalkneethling>
ok, no I read it correctly

[03:27:52.0000] <schalkneethling>
now

[03:27:58.0000] <schalkneethling>
got it, so the same goes for muted

[03:28:08.0000] <schalkneethling>
thanks for the feedback zcorpan

[03:28:11.0000] <zcorpan>
you may want to read html.spec.whatwg.org instead

[03:36:08.0000] <MikeSmith>
anybody know what plans, if any, WebKit has for actually implementing document.execCommand("cut"/"copy")

[03:36:46.0000] <MikeSmith>
I found https://bugs.webkit.org/show_bug.cgi?id=146336, which has an amusing summary but is otherwise not terrifically enlightening

[03:37:03.0000] <MikeSmith>
it's implemented now everywhere else, right?

[03:37:16.0000] <MikeSmith>
gecko, blink, edge

[03:58:33.0000] <mkwst>
annevk: Any ideas about the right way to address https://www.w3.org/Bugs/Public/show_bug.cgi?id=27190?

[04:23:51.0000] <mkwst>
annevk: also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27146.

[04:28:12.0000] <annevk>
mkwst: the latter seems doable

[04:28:22.0000] <annevk>
mkwst: the former is still unclear on what invariants we want to preserve

[04:28:34.0000] <annevk>
mkwst: I emailed public-webappsec about that as well at some point but to no avail

[04:29:28.0000] <mkwst>
annevk: yeah. fixing the latter would be nice, since it seems straightforward.

[04:29:58.0000] <annevk>
mkwst: I'm in the midst of trying to do Fetch refactoring and it's going rather slowly

[04:30:36.0000] <mkwst>
annevk: For the former, I've updated the algorithm a bit to define behavior for workers and sharedworkers that I think is sane: https://w3c.github.io/webappsec/specs/powerfulfeatures/#settings-secure step 2.*.

[04:30:56.0000] <mkwst>
annevk: If you're fine with the change, I'll poke at it. No reason for you to do it.

[04:33:58.0000] <annevk>
mkwst: yeah that seems like a good change to make

[04:34:41.0000] <mkwst>
Did you kill Request/Response's TLS state?

[04:34:54.0000] <mkwst>
I don't see them in Fetch anymore.

[04:35:35.0000] <mkwst>
Ah, "HTTPS state".

[04:36:15.0000] <annevk>
OE ruined the term TLS for me

[04:43:28.0000] <mkwst>
Yup. Totally understood.

[04:47:53.0000] <Ms2ger>
OE?

[04:48:38.0000] <mkwst>
opportunistic encryption

[04:48:59.0000] <Ms2ger>
Ah

[06:42:55.0000] <MikeSmith>
so I am going to experiment with using the term "the Web runtime" in conversations instead of "the Web platform"

[06:44:34.0000] <MikeSmith>
the reason being that I am increasingly running into people who are using "the Web platform" to mean either just "the Web" or else basically whatever they want it to mean such that there pet technology is part of it

[06:44:55.0000] <MikeSmith>
e.g., claims that EPUB is part of the Web platform

[06:45:12.0000] <MikeSmith>
or that Linked Data is part of the Web platform

[06:45:14.0000] <MikeSmith>
etc.

[06:46:09.0000] <wanderview>
annevk: I have not had a chance to look at the pull request and probably won't in the next couple weeks... feeling the crunch trying to get service workers in 43

[06:47:30.0000] <annevk>
wanderview: ok, thank you

[07:09:45.0000] <gsnedders>
nox: takk

[07:11:18.0000] <annevk>
MikeSmith: see HTML5 and other terms

[07:11:20.0000] <annevk>
MikeSmith: uphill battle

[07:11:46.0000] <MikeSmith>
true

[07:12:37.0000] <annevk>
Man, image fetching is complicated

[07:12:37.0000] <MikeSmith>
but the advantage "the Web runtime" is that it's not an attractive term for others to try to shoehorn their non-Web junk into

[07:12:55.0000] <jgraham>
I'm not sure why not

[07:13:10.0000] <jgraham>
The point is that it's a popular thing, not the specific choice of words

[07:13:30.0000] <MikeSmith>
sure

[07:13:44.0000] <annevk>
If we're going to pick new terms I guess I'd go with Web Kernel

[07:13:47.0000] <jgraham>
I'm sure ePub or whoever would happilly talk about "HTML5 technology" whilst requiring XHTML1.1 or similar

[07:14:52.0000] <MikeSmith>
well that's exactly the case with epub currently

[07:15:03.0000] <jgraham>
"Kernel" seems like a misuse of the term. Plus it makes me think of matricies. And nuts.

[07:15:08.0000] <MikeSmith>
it's well-formed XHTML only

[07:15:14.0000] <MikeSmith>
I like it

[07:15:19.0000] <MikeSmith>
Kernel

[07:15:38.0000] <MikeSmith>
you can't pile tons of crap into the kernal

[07:16:03.0000] <jgraham>
Well that pretty much precludes the web from using it then :p

[07:16:09.0000] <MikeSmith>
it implies something bounded

[07:16:10.0000] <MikeSmith>
hah

[07:16:16.0000] <MikeSmith>
zing

[07:20:06.0000] <nox>
gsnedders: For what?

[07:20:43.0000] <gsnedders>
nox: https://github.com/html5lib/html5lib-tests/pull/67#issuecomment-138864769

[07:21:24.0000] <nox>
gsnedders: Blink TC?

[07:21:47.0000] <gsnedders>
nox: your two tests are equivilant to the Blink test case

[07:23:19.0000] <nox>
gsnedders: Right.

[07:23:34.0000] <nox>
gsnedders: I suppose in Blink all three produce the same tree shape?

[07:23:39.0000] <gsnedders>
yeah

[07:23:57.0000] <nox>
gsnedders: We agree that Blink is broken, then?

[07:24:00.0000] <gsnedders>
Yes.

[07:24:56.0000] <nox>
gsnedders: lol @ that isindex test.

[07:25:46.0000] <nox>
gsnedders: Could you enforce that tests should only be appended to the existing tests, btw?

[07:26:11.0000] <nox>
gsnedders: To ignore the ones we don't pass in html5ever, we use their index in the file.

[07:28:54.0000] <gsnedders>
nox: IMO that doesn't make so much sense as putting stuff as close to possible to a similar test

[07:29:04.0000] <Ms2ger>
That sounds like a bad idea :)

[07:29:08.0000] <gsnedders>
nox: I suggest you use some simple hashing function to reference them

[07:29:55.0000] <nox>
 Ms2ger: The enumeration? That's not me.

[07:30:08.0000] <gsnedders>
Anyhow, I'm going out for a bit.

[08:36:44.0000] <Domenic>
annevk: regarding ruby https://github.com/whatwg/html/pull/101#issuecomment-138949170 can you confirm with a live-dom-viewer test case that WebKit and Gecko currently differ?

[08:38:20.0000] <Domenic>
I guess I can use my iPad

[08:38:35.0000] <Domenic>
<rtc><rb> right?

[08:46:07.0000] <annevk>
Domenic: yeah, I did that the other day

[08:46:22.0000] <Domenic>
annevk: They apparently do not differ, for <rtc><rp>

[08:46:32.0000] <Domenic>
children in both

[08:47:57.0000] <annevk>
Domenic: do you have <ruby> in scope?

[08:48:07.0000] <Domenic>
Oh, no, didn't test that :P

[08:48:35.0000] <Domenic>
dammit

[08:49:33.0000] <annevk>
heh

[08:50:21.0000] <annevk>
I'm going to be splitting some of this Fetch stuff out, will be too much at once otherwise I'm afraid

[08:50:43.0000] <annevk>
and I'm getting nowhere near completion working on a big patch like this, so hopefully that's somewhat fruitful

[08:52:02.0000] <caitp>
you can do it

[08:55:03.0000] <annevk>
Domenic: http://trac.webkit.org/changeset/172834/trunk/Source/WebCore/html/parser/HTMLTreeBuilder.cpp mentioned by Koji is relevant

[08:55:19.0000] <annevk>
Domenic: also https://github.com/w3c/html/commit/c61397b989b28235ee2228f280aa8d475f3b9ebf

[08:55:35.0000] <Domenic>
annevk: so is the idea that this just hasn't made it into Safari yet?

[08:55:38.0000] <annevk>
Domenic: that's the relevant change between HTML5 and HTML51

[08:55:40.0000] <Domenic>
Maybe someone with OS X beta can test

[08:55:54.0000] <annevk>
Domenic: I'm guessing that indeed stable Safari is over a year old

[08:55:57.0000] <caitp>
is webkit nightly not good enough for testing?

[08:56:23.0000] <annevk>
When I tried WebKit nightly a long time ago I couldn't really get it to work

[08:56:24.0000] <Domenic>
Not on PCs it's not

[08:56:26.0000] <annevk>
Maybe I should try again

[08:56:42.0000] <caitp>
i didn't know there was a pc version, since it just hijacks safari I think

[08:57:05.0000] <Domenic>
I was being oblique. The reason I can't test is because there is no PC version.

[08:57:12.0000] <Domenic>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cruby%3E%3Crtc%3E%3Crp%3E for anyone with WebKit nightly or Safari beta

[08:57:43.0000] <Domenic>
But regardless sounds like there's consensus

[08:57:46.0000] <annevk>
I'm surprised Ryosuke r+'d http://trac.webkit.org/changeset/172834/trunk/Source/WebCore/html/parser/HTMLTreeBuilder.cpp given that it didn't reference a stable draft

[08:57:51.0000] <annevk>
</troll>

[09:16:03.0000] <Domenic>
Wow, some very aggressive URL issue filing going on

[09:26:57.0000] <Domenic>
Ah somehow I knew this would go in the tone policing direction the moment we called her out on harassment

[09:31:17.0000] <annevk>
Domenic: what do you call something that doesn't depend on global state?

[09:31:34.0000] <tantek>
/me perks up at tone policing and harrassment.

[09:31:36.0000] <Domenic>
ahhh there is a term for this

[09:31:39.0000] <tantek>
Domenic: URL?

[09:31:53.0000] <annevk>
Pure

[09:31:55.0000] <Domenic>
http://c2.com/cgi/wiki?GlobalVariablesAreBad

[09:31:59.0000] <tantek>
annevk: stateless ?

[09:32:16.0000] <Domenic>
stateless is the one you want yeah

[09:32:18.0000] <nox>
Domenic: Link?

[09:32:20.0000] <Domenic>
pure is pretty good too

[09:32:31.0000] <tantek>
pure sounds too fluffy

[09:32:44.0000] <annevk>
well, https://en.wikipedia.org/wiki/Pure_function

[09:33:37.0000] <tantek>
wow what - that seems completely made up

[09:33:46.0000] <tantek>
yesh "This article needs additional citations for verification. "

[09:34:01.0000] <tantek>
I'd have to ask Knuth about his opinion on this

[09:35:09.0000] <Domenic>
She's unleashed her Twitter on us by the way, in case you wonder where the randoms come from

[09:35:26.0000] <tantek>
Domenic: URL?

[09:35:34.0000] <Domenic>
https://github.com/whatwg/url/issues/71

[09:35:44.0000] <tantek>
also re: pure http://mathematica.stackexchange.com/questions/64577/why-does-the-documentation-call-functions-pure/64624#64624 " In the Wikipedia article it is a term extracted by analogy from the increasingly popular term "purely functional" which refers (mainly) to deterministic programming free of side-effects."

[09:36:18.0000] <tantek>
Domenic: wow wtf

[09:36:36.0000] <Domenic>
pure function is a pretty well established term...

[09:36:39.0000] <annevk>
I remember reaching out to some part of the community before, e.g., I discussed this with wycats

[09:36:52.0000] <Ms2ger>
/me sighs at people who think sending their twitter followers into a bug trackers does anything else than make them look like idiots

[09:36:53.0000] <annevk>
And es-discuss, etc.

[09:37:14.0000] <Ms2ger>
tantek, what do you think a pure function is, then?

[09:37:33.0000] <tantek>
Ms2ger: see above mathematica article - is the term needed?

[09:37:52.0000] <tantek>
also, maybe I should try sending Twitter followers into a CSS discussion

[09:39:52.0000] <tantek>
huh - that issue 71 was more interesting than I expected

[09:40:34.0000] <tantek>
I'm for not depending on window.location - because - hey, there's no window.location in Node.js right? URL is intended to be used there too right?

[09:40:59.0000] <tantek>
this doesn't seem like a matter of defaults or not

[09:41:09.0000] <tantek>
but rather of predictable / consistent behavior

[09:41:20.0000] <Domenic>
yeah wasn't sure whether to bring that up, but yeah, URL is a generic URL processing library.

[09:42:03.0000] <nox>
I've had sufficiently unexpected relative URL crap happening to think that this is a bad idea, global variables or not.

[09:42:37.0000] <caitp>
wouldn't it be doable to have a wrapper on top of the URL primitive which does the relative URL thing?

[09:42:46.0000] <caitp>
or like a static method or something

[09:42:50.0000] <annevk>
yeah

[09:42:54.0000] <Domenic>
Your points would be appreciated in the thread, as her Twitter horde has descended with the Lea-is-right viewpoint

[09:43:01.0000] <annevk>
though you could also just pass in document.baseURI or some such

[09:43:10.0000] <annevk>
location seems actually wrong

[09:43:10.0000] <Domenic>
or document.URL

[09:43:15.0000] <Domenic>
which one? who knows

[09:43:21.0000] <tantek>
/me gets the popcorn

[09:43:27.0000] <ato>
annevk: I have no idea whether this is valid criticism: https://twitter.com/LeaVerou/status/641641311427100676

[09:43:50.0000] <tantek>
good defaults for UIs, not APIs. sheesh

[09:44:40.0000] <ccardona-work>
: Good morning/afternoon/evening WHATWG crew o/

[09:45:07.0000] <MikeSmith>
"The W3C priority of constituencies puts theoretical purity at the very bottom"

[09:45:08.0000] <tantek>
/me can't tell if slightlyoff is serious or not.

[09:45:24.0000] <annevk>
tantek: I think he is

[09:45:40.0000] <caitp>
there was no :p in his comment

[09:46:01.0000] <slightlyoff>
actually serious

[09:46:11.0000] <annevk>
Given how strong the JavaScript default library likes to avoid global state I'm somewhat surprised by those comments

[09:46:17.0000] <tantek>
indeed

[09:46:37.0000] <annevk>
But you know, I guess folks care about different things which is alright

[09:46:55.0000] <annevk>
And I guess asking people to be polite is no longer done :-(

[09:47:12.0000] <slightlyoff>
annevk: TC39 hasn't yet accepted it works on a web language and that origins are our security model...which is maddening

[09:47:29.0000] <annevk>
slightlyoff: orthogonal

[09:47:34.0000] <slightlyoff>
but whatwg is under no pressure to replicate those mistskes

[09:48:33.0000] <tantek>
anyone looked at the URL objects in other languages? or do I need to go get my big table again?

[09:49:44.0000] <caitp>
most other languages don't have the same relationship with an origin

[09:51:10.0000] <wanderview>
Domenic: fwiw, she raised the issue on twitter first and I asked her to file the issue

[09:51:22.0000] <caitp>
the `location.relativeURL()` idea seems pretty good

[09:54:07.0000] <slightlyoff>
yeah, I suggested statics in the bug to separate out relative/absolute parsing behaviour. Might also split the types to prevent inadvertent mixing

[09:54:54.0000] <slightlyoff>
(this type feels overloaded and should unpack the "has a"s from the "is a" s)

[09:55:34.0000] <Domenic>
this type is about absolute URLs

[09:55:47.0000] <annevk>
slightlyoff: overloaded? How?

[09:55:52.0000] <Domenic>
it's not overloaded but people's conception of URLs is overloaded so they think it can do multiple things it cannot normally do

[09:56:09.0000] <annevk>
Yeah, so far from that thread it seems folks are confused about URLs

[09:56:54.0000] <Domenic>
One of the stronger practical arguments for me is that half the time you want document.URL and half the time you want document.baseURI

[09:57:41.0000] <Domenic>
afk for lunch, don't blow up the internet

[09:57:52.0000] <annevk>
I feel a bit sad about it escalating so quickly. I wonder how to approach something like this next time around

[09:58:22.0000] <TabAtkins>
annevk: Imma see if I can chat at Lea and ask her not to escalate to mob immediately. :/

[10:03:52.0000] <wanderview>
annevk: I know it may not be fair, but I think trying to look past insults ("no hci training") and focus on the technical reasons for the decision helps keep things from escalating

[10:07:05.0000] <annevk>
wanderview: yeah, I guess I should've not gone into that

[10:07:20.0000] <annevk>
wanderview: it felt a bit unfair

[10:07:33.0000] <wanderview>
annevk: it is unfair!  I only mentioned it since you asked about avoiding escalation

[10:08:28.0000] <wanderview>
I try to think about it like the old browser networking rule... be thick skinned about what you receive and use a light touch with what you send

[10:14:05.0000] <TabAtkins>
No, it was quite unfair. Lea jumps in with her qualifications when it's relevant; assuming non-qualifications on others (and then calling tone-police when it's pointed out) was somewhat shitty. :/

[10:20:35.0000] <TabAtkins>
Is window.location changeable?  Without navigating?

[10:20:44.0000] <TabAtkins>
I forget what exactly is mutatable here, because it doesn't make sense.

[10:20:45.0000] <jgraham>
/me refuses to listen to anyone without a CS degree

[10:21:45.0000] <annevk>
TabAtkins: pushState()

[10:21:57.0000] <TabAtkins>
Right, thanks.

[10:22:04.0000] <annevk>
TabAtkins: but window.location seems wrong since it doesn't take into account <base>

[10:22:17.0000] <gsnedders>
jgraham: Oh, good to know we should refuse to listen to you.

[10:22:30.0000] <annevk>
TabAtkins: which is part of why it's magical, since folks assume location, but that'd be really bad

[10:22:42.0000] <annevk>
I dunno

[10:22:58.0000] <slightlyoff>
annevk: overloaded in the sense that there are folks trying to use relative URL fragments and absolute URLs inside the same programs. URL (today) have a `pathname` component, but that's only a look-alike

[10:23:18.0000] <annevk>
slightlyoff: I'm not following you

[10:23:22.0000] <slightlyoff>
annevk: and anyone who wants to parse parts of a URL without committing to creating an absolute URL is SOL

[10:23:37.0000] <annevk>
slightlyoff: we don't have a relative URL primitive in the platform today

[10:24:17.0000] <slightlyoff>
...hence people trying to use URL for things that aren't what you've spec'd the API to to include are finding it difficult to work with = )

[10:25:00.0000] <TabAtkins>
And hence why URL, which is trying to handle absolute urls, shouldn't try to handle relative urls.

[10:25:02.0000] <caitp>
getting rid of the 2nd parameter entirely and just adding a static method for that seems easier to understand

[10:25:28.0000] <TabAtkins>
caitp: That's another option, yeah (and I think it's better ergonomics).

[10:27:58.0000] <annevk>
slightlyoff: are you saying folks want a relative URL primitive?

[10:28:07.0000] <annevk>
hmm, gotta go

[10:28:21.0000] <slightlyoff>
I'm asking you to look more deeply into what she's trying to accomplish in this case

[10:28:33.0000] <slightlyoff>
and instead of writing her off, ask why the current system seemed broken

[10:28:46.0000] <slightlyoff>
maybe the form of what she's asking for is wrong

[10:28:55.0000] <slightlyoff>
(I suggested statics because I'd find that clearer)

[10:29:40.0000] <slightlyoff>
but it may be that a RelativeURL or URLComponent would help clarify things

[10:30:45.0000] <caitp>
seems like it would make things more complicated, tbh

[10:31:19.0000] <caitp>
unless it was just a subclass of URL with an extra `base` attribute or something

[10:35:11.0000] <TabAtkins>
I mean, being able to pass around relative urls seems potentially useful. I'd have to dig for use-cases, but I can see it theoretically, with an explicit resolve() method to turn it into a URL.

[10:35:32.0000] <TabAtkins>
Probably want to not give it a toString(), to make it harder to misuse.

[10:35:39.0000] <gsnedders>
I for one would expect URL to act like any href in a document, FWIW.

[10:36:03.0000] <caitp>
tell that to the node-compat people =p

[10:36:03.0000] <botie>
will do

[10:36:26.0000] <TabAtkins>
gsnedders: THAT'S THE PROBLEM

[10:36:27.0000] <gsnedders>
If I can claim to be a web developer nowadays.

[10:36:34.0000] <TabAtkins>
href in a document depends on <base>

[10:36:36.0000] <gsnedders>
TabAtkins: STOP TONE-POLICING ME.

[10:36:41.0000] <TabAtkins>
href outside a document depends on window.location

[10:36:47.0000] <TabAtkins>
Neither is the origin.

[10:36:58.0000] <gsnedders>
wait, what

[10:37:00.0000] <gsnedders>
what's the second case?

[10:37:07.0000] <gsnedders>
href *outside* a document?

[10:37:09.0000] <gsnedders>
when is that?

[10:37:11.0000] <TabAtkins>
An <a> created in script and not inserted into a document.

[10:37:34.0000] <gsnedders>
so its ownerDocument doesn't matter here? huh.

[10:37:39.0000] <TabAtkins>
Yeah.

[10:37:43.0000] <caitp>
really? that might have an impact on all those URL polyfills then

[10:37:56.0000] <TabAtkins>
Or maybe ownerDocument does, but at least <base> doesn't.

[10:38:02.0000] <gsnedders>
ok, shit, you've just made everything more complicated.

[10:38:19.0000] <jgraham>
You sound surprised

[10:38:33.0000] <TabAtkins>
Or it does? Man, I dunno. Shit's complicated, yes.

[10:38:39.0000] <gsnedders>
jgraham: I only have half a degree in CS. You should be ignoring half of what I say.

[10:39:01.0000] <gsnedders>
jgraham: And hence either I'm surprised but you don't know what about, or you know what I'm talking about but not that I'm surprised.

[10:39:10.0000] <caitp>
did you tear the paper in half?

[10:39:40.0000] <jgraham>
gsnedders: If I'm to ignore half of what you say, which parts would you like me to start paying attention to?

[10:40:18.0000] <slightlyoff>
TabAtkins: if you don't give it a toString (which is pretty punitive), then the lack of equality method in URLs comes glaring through

[10:40:44.0000] <TabAtkins>
True fact! That's because relative urls, without a notion of where they're resolved against, have a very shaky notion of "equality"!

[10:40:51.0000] <gsnedders>
caitp: I have what en-us would call a joint major.

[10:41:14.0000] <caitp>
oh I see

[10:41:17.0000] <TabAtkins>
Grabbing a relative url from an <a> and from a background-image mean different things, even if they stringify the same.

[10:41:58.0000] <caitp>
probably a better choice in that case

[10:42:29.0000] <TabAtkins>
slightlyoff: Relative urls are fraught with footguns, despite (rather, due to) their usability.

[10:43:22.0000] <gsnedders>
TabAtkins: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3630

[10:43:39.0000] <TabAtkins>
Yeah, I was just experimenting with it, too.

[10:43:52.0000] <TabAtkins>
Which makes it EVEN WORSE, as defaulting to location would *not* correspond to what <a> does!

[10:44:04.0000] <gsnedders>
tl;dr: I'd expect URL to resolve against the same thing new_a does.

[10:44:15.0000] <slightlyoff>
same

[10:44:28.0000] <gsnedders>
/me comments as such

[10:45:01.0000] <tantek>
usually I like convenient defaults, in this case the predictability of code makes me prefer (as an *author*) that bugs show up as errors sooner, thus no auto-magic relative URL resolution

[10:45:19.0000] <tantek>
I think it's bad idea to grandfather the rushed APIs of new_a etc. into URL

[10:45:39.0000] <gsnedders>
As an author I'd expect consistency with new_a etc.

[10:45:51.0000] <jgraham>
FWIW I think we have been bitten over and over again by dwim in APIs

[10:45:57.0000] <gsnedders>
dwim?

[10:46:05.0000] <jgraham>
Do What I Mean

[10:46:09.0000] <gsnedders>
/me only skimmed the first half of this conversation

[10:46:22.0000] <tantek>
gsnedders: that's a way to write code that fails silently and late

[10:46:24.0000] <caitp>
here's an idea: what if the primitive is totally separate from Location and stuff, and has nothing whatsoever to do with those, and instead other interfaces provide helpers for constructing URL objects resolved the way they would

[10:46:38.0000] <gsnedders>
tantek: perhaps. :)

[10:46:39.0000] <tantek>
gsnedders: when have you used new_a on what site?

[10:46:53.0000] <caitp>
that way everyone is happy

[10:47:04.0000] <tantek>
gsnedders: I much prefer writing code that I have more confidence in "leaving alone" and knowing there is less chance of it failing later silently

[10:47:12.0000] <TabAtkins>
caitp: location.relativeURL(), document.relativeURL() ^_^

[10:47:23.0000] <caitp>
exactly

[10:47:24.0000] <TabAtkins>
document.styleSheets[0].relativeURL()

[10:47:45.0000] <TabAtkins>
Make a mixin interface for relative urls, apply it to any interface that has a notion of "base url".

[10:48:36.0000] <caitp>
I'd find that pretty easy to use, without accidentally making bogus URLs

[10:48:45.0000] <nox>
I would just add that to URLUtilsReadOnly and URLUtils.

[10:49:09.0000] <gsnedders>
nox: you Rust people and your immutability! :P

[10:49:15.0000] <nox>
What?

[10:50:11.0000] <gsnedders>
nox: you're just extending mutability from the type-system to object-indentity in other languages!

[10:50:18.0000] <nox>
gsnedders: For starters, I fancy immutability because I come from the terse land of Erlang. :P

[10:51:10.0000] <nox>
gsnedders: And why would putting relativeURL() in URLUtils{,ReadOnly} related to my taste for immutability?

[10:51:53.0000] <gsnedders>
nox: it's having the real only variant in the first place

[10:52:01.0000] <nox>
gsnedders: Oh!

[10:52:37.0000] <nox>
gsnedders: When I wrote "URLUtils{,ReadOnly}" I thought "why didn't I put them in alphabetic order previously?".

[10:52:47.0000] <nox>
That explains things.

[10:52:52.0000] <TabAtkins>
We can have a readonly variant when we can have object equality work properly, and not a moment before.

[10:53:07.0000] <gsnedders>
TabAtkins: does .valueOf not work for this?

[10:53:09.0000] <nox>
TabAtkins: URLUtilsReadOnly exists already.

[10:53:28.0000] <TabAtkins>
gsnedders: Nope, not if you're comparing two objects.

[10:53:39.0000] <TabAtkins>
Two objects => immediate pointer comparison.

[10:53:42.0000] <caitp>
doesn't object equality work well when you're only dealing with absolute urls?

[10:53:52.0000] <TabAtkins>
valueOf/toString are only invoked when comparing against primitives.

[10:53:54.0000] <gsnedders>
TabAtkins: bah, it's been too long

[10:53:57.0000] <caitp>
I mean

[10:54:03.0000] <caitp>
apart from not being able to overload the equality operator

[10:54:13.0000] <TabAtkins>
caitp: That's the entire point. ^_^

[10:54:15.0000] <nox>
caitp: Yeah, I'm not sure why relative URLs matter here, aren't we discussing urlutils.relativeURL(string) -> URL?

[10:54:16.0000] <gsnedders>
TabAtkins: can you tell I haven't touched a JS engine in three years?

[10:54:39.0000] <nox>
TabAtkins: I thought relativeURL() would return a new absolute URL, resolving its argument against the context object?

[10:54:55.0000] <caitp>
URL.is(url1, url2) ?

[10:55:05.0000] <caitp>
:<

[10:55:14.0000] <TabAtkins>
caitp: Yeah, that exists now.

[10:55:24.0000] <caitp>
didn't know that

[10:55:41.0000] <gsnedders>
can we just throw JS out and start with a new language? #trollololol

[10:56:09.0000] <TabAtkins>
nox: Yes, correct.

[10:56:16.0000] <TabAtkins>
Maybe better to call it "resolveURL()"

[10:56:24.0000] <caitp>
I don't actually see that mentioned in the spec though

[10:56:25.0000] <nox>
TabAtkins: Oh I see, you are just saying == doesn't do the thing we want,

[10:56:25.0000] <TabAtkins>
To not imply that it returns a relative url object.

[10:56:30.0000] <TabAtkins>
Yeah.

[10:56:38.0000] <gsnedders>
TabAtkins: hasn't it already shipped?

[10:56:38.0000] <caitp>
"resolveURL" is probably more confusing to authors though

[10:56:39.0000] <nox>
TabAtkins: but how is this related to whether we put it on the ReadOnly interface?

[10:56:47.0000] <TabAtkins>
URL("http://example.com") == URL("http://example.com") is false

[10:56:47.0000] <gsnedders>
TabAtkins: there again, you do like renaming things at LC…

[10:56:52.0000] <nox>
I suggest sympathise(),

[10:56:53.0000] <TabAtkins>
nox: It's... not?

[10:57:01.0000] <nox>
stands for relate().

[10:57:02.0000] <gsnedders>
TabAtkins: (no, we're not letting you forget this)

[10:57:09.0000] <TabAtkins>
gsnedders: Hasn't what already shipped?

[10:57:24.0000] <nox>
TabAtkins: I don't understand "We can have a readonly variant when we can have object equality work properly, and not a moment before." then. :)

[10:58:00.0000] <caitp>
maybe value types will be a thing some day

[10:58:01.0000] <TabAtkins>
nox: Oh! That's about value objects. Value objects are readonly, and get structural equality automatically, *and* can overload == if they want.

[10:58:17.0000] <nox>
TabAtkins: Oh, ok.

[10:58:23.0000] <caitp>
i thought they just had structural equality

[10:58:29.0000] <TabAtkins>
caitp: They're absolutely coming - we've got people working on them.

[10:58:30.0000] <caitp>
when did the overloading == thing come in?

[10:58:32.0000] <nox>
TabAtkins: I had mentioned URLUtilsReadOnly just before, so I was lost.

[10:58:43.0000] <TabAtkins>
nox: Yeah, sorry about that confusion.

[10:58:45.0000] <gsnedders>
TabAtkins: all the URL stuff?

[10:59:00.0000] <TabAtkins>
caitp: Operator overloading has been part of the value objects proposal since forever. It's still... hard, but it'll happen.

[10:59:10.0000] <TabAtkins>
They're not super useful without.

[10:59:15.0000] <nox>
TabAtkins: No problem.

[10:59:21.0000] <caitp>
Tab: I recall it was always problematic to overload equality ops in particular because of invariant violations (also certain other ops)

[10:59:24.0000] <TabAtkins>
If you have to do .add(), etc when you use an int64, that's shitty.

[10:59:25.0000] <caitp>
did that change?

[10:59:41.0000] <TabAtkins>
caitp: Nah, === is *not* overridable, nor is != (it's derived from ==).

[11:00:01.0000] <nox>
(Later on Twitter: "Goddammit, TabAtkins can't talk intelligibly from his ivory tower!!1!)

[11:00:01.0000] <TabAtkins>
That's enough.

[11:00:05.0000] <caitp>
I guess we'll have to change jshint to stop warning about === then

[11:00:16.0000] <TabAtkins>
Why would it warn about ===?

[11:00:22.0000] <caitp>
er, == vs ===

[11:00:29.0000] <caitp>
if you need == for structural equality, I mean

[11:00:44.0000] <TabAtkins>
Nah, === is *always* structural equality. == defaults to that, but can be overridden.

[11:01:10.0000] <TabAtkins>
Best of primitives and objects, in one thing.

[11:01:33.0000] <caitp>
and I assume it fast-cases if objects are reference-equal

[11:01:47.0000] <caitp>
words are hard I need coffee

[11:12:12.0000] <nox>
annevk: Are PRs that just simplify algorithms while keeping current behaviour welcomed?

[11:13:32.0000] <smaug____>
as a spec reader and reviewer, I'd say those are most welcome

[11:18:36.0000] <tantek>
indeed

[12:16:18.0000] <TabAtkins>
caitp: Yeah, that's all under the covers. Same-object is obviously structurally equal.

[12:23:34.0000] <annevk>
nox: yes

[12:25:11.0000] <annevk>
slightlyoff: I'm not opposed to adding things, I just disagreed that new URL shouldn't be a pure function

[12:26:58.0000] <annevk>
slightlyoff: all about layering

[12:33:57.0000] <slightlyoff>
What?

[12:34:19.0000] <slightlyoff>
nothing about changing the (default) inputs of the function invalidates the notion of a "pure function" here

[12:34:27.0000] <slightlyoff>
(same inputs generating the same output w/o side effects)

[12:35:11.0000] <slightlyoff>
Again, happy to see other ways to untangle this (e.g. static)

[12:35:12.0000] <caitp>
couldn't asking for an attribute of location or document be considered a side effect

[12:35:16.0000] <slightlyoff>
s/static/statics/

[12:36:08.0000] <slightlyoff>
only if that changes something about the state of the world; i.e. if it invokes a getter that does stuff, but we're talking about JS here, the notion of a "pure function" in JS is pretty laughable most of the time...you only get it through convention in this language

[12:36:18.0000] <slightlyoff>
(i.e. we don't have value types)

[12:38:02.0000] <slightlyoff>
for instance: https://url.spec.whatwg.org/#constructors seems to coerce to a string

[12:38:32.0000] <slightlyoff>
which means you're calling toString() on some object, which can have whatever side-effects you can imagine (boiling of oceans on distant moons)

[12:38:54.0000] <annevk>
slightlyoff: yeah, what it doesn't mean though is that URL needs to depend on DOM

[12:39:03.0000] <annevk>
slightlyoff: or HTML or some such

[12:39:06.0000] <slightlyoff>
so that's a *totally differet* objection

[12:39:10.0000] <slightlyoff>
(different)

[12:39:34.0000] <annevk>
slightlyoff: well, I might have several then

[12:40:40.0000] <annevk>
slightlyoff: new URL not depending on global state seems like a good thing too, for portability reasons and understanding what it actually does

[12:41:34.0000] <slightlyoff>
now we're getting somewhere

[12:42:05.0000] <slightlyoff>
you think it's easier to understand, others (seem to?) disagree. That's fine. I've asked Lea to outline her use-case in more depth

[12:42:12.0000] <annevk>
I don't know, you, wycats, and I discussed this a long time ago and agreed

[12:42:27.0000] <wycats>
which thing?

[12:42:46.0000] <slightlyoff>
but we can't talk about this as being some bedrocky CS principle when it's all ergonomics and choices under uncertainty

[12:42:57.0000] <annevk>
wycats: about URL constructors

[12:43:28.0000] <wycats>
slightlyoff: I don't have a ton of time, but choosing not to call toString on something is a heavy choice

[12:43:29.0000] <wycats>
it better be worth it

[12:43:58.0000] <caitp>
it's clear that on the web you probably do want to get the url resolved relative to <base>, what if you want a different one resolved relative to origin, or a different one resolved relative to file

[12:44:08.0000] <slightlyoff>
wycats: I'm not saying we shouldn't call toString

[12:44:12.0000] <tantek>
even such bedrocky CS principles are supposed to be based in practical needs - so if you can't explain it in terms of such, then perhaps it's a misapplication of the principle

[12:44:15.0000] <slightlyoff>
wycats: I'm arguing that you obviously should (and do)

[12:44:37.0000] <wycats>
is the question what the default base is?

[12:44:44.0000] <slightlyoff>
wycats: yes; that's the debate

[12:44:47.0000] <wycats>
why not just give host environments a hook to configure it and call it a day

[12:45:05.0000] <wycats>
node probably wants something different anyawy

[12:45:07.0000] <wycats>
anyway*

[12:45:19.0000] <caitp>
because then it will make the api behave differently in different environments, and then joe's "orthogonal JS" won't do the right thing

[12:45:26.0000] <tantek>
/me suspects any sentence with "just"

[12:45:27.0000] <caitp>
orthogonal?

[12:45:49.0000] <caitp>
wrong word, not enough sleep :<

[12:45:51.0000] <slightlyoff>
yeah, I'm up for that. I think annevk is opposed. Regardless I think we need to think about what statics URL needs for convenience as lots of people are tripped up trying to accomplish a lot of different goals by the "construct a URL, and first read up on all the details of URL" thing

[12:46:45.0000] <annevk>
slightlyoff: I think ergonomics are important, but simple building blocks are too

[12:46:56.0000] <annevk>
slightlyoff: would folks expect that invoking pushState() changes how new URL() works?

[12:47:18.0000] <wycats>
annevk: at minimum, we could have an option that explicitly asks for "host specified base"

[12:47:21.0000] <annevk>
slightlyoff: or would that be called "magic" and the platform trying to be clever again?

[12:47:23.0000] <wycats>
which seems useful

[12:47:29.0000] <annevk>
wycats: well that's the second argument

[12:47:41.0000] <wycats>
annevk: can you say "whatever the host thinks a good option is"?

[12:47:58.0000] <wycats>
annevk: I don't really understand the universal JS point

[12:48:14.0000] <wycats>
presumably if there's no host-configured base, and you pass a relative URL, you'd get an exception?

[12:48:27.0000] <annevk>
wycats: if you don't pass a base URL, yes

[12:48:29.0000] <slightlyoff>
annevk: its' only "clever" if we're trying to predict use as opposed to responding to existing user needs

[12:48:42.0000] <wycats>
annevk: so then slightlyoff is right

[12:48:49.0000] <wycats>
why are you giving a relative URL if you want "agnostic" behavior

[12:48:53.0000] <wycats>
that doesn't make any sense

[12:48:59.0000] <wycats>
a relative URL must be relative to something

[12:49:01.0000] <annevk>
wycats: you might want to actually make sure you're given an absolute URL

[12:49:12.0000] <annevk>
wycats: there's a ton of places in the platform that want this

[12:49:13.0000] <wycats>
sounds like a good utility to include, which iirc we do

[12:49:24.0000] <wycats>
you should not be invoking the constructor to get an exception to learn that

[12:49:25.0000] <wycats>
that's silly

[12:49:26.0000] <slightlyoff>
/me frames wycats saying I was right about something

[12:49:37.0000] <wycats>
lololol

[12:49:55.0000] <wycats>
the lack of a URL.isAbsolute(url) seems like the problem here

[12:50:45.0000] <annevk>
Yeah, we should probably offer that

[12:51:03.0000] <caitp>
do you differentiate between absolute and fully qualified

[12:51:24.0000] <annevk>
I'm not sure what the distinction would be

[12:51:30.0000] <annevk>
But absolute URL per spec is syntax

[12:51:57.0000] <annevk>
The outcome of the parser is a URL record https://url.spec.whatwg.org/#concept-url

[12:52:02.0000] <caitp>
absolute urls in <a> terms would be relative to base

[12:52:17.0000] <caitp>
versus fully qualified which include scheme/host/etc

[12:52:18.0000] <annevk>
well if they're absolute the base is irrelevant

[12:52:29.0000] <annevk>
I think you're confusing things

[12:52:40.0000] <annevk>
You might be thinking about path-absolute URLs?

[12:52:59.0000] <caitp>
it's not a confusion, they're different things

[12:53:31.0000] <annevk>
I guess what you're calling absolute the spec calls path-absolute and what you're calling fully qualified the spec either calls absolute or URL records...

[12:54:39.0000] <annevk>
wycats: so I guess you changed your mind too or maybe I misremembered

[12:54:45.0000] <wycats>
annevk: I have to go momentarily, but do you get my basic point?

[12:54:52.0000] <wycats>
if it would be an exception anyway, it seems ok to configure it

[12:55:02.0000] <wycats>
as long as there's a way to defend yourself if you really care

[12:55:11.0000] <annevk>
wycats: I'm not sure if we can still change this at this point, but perhaps we could make it configurable...

[12:55:30.0000] <wycats>
if it's an exception now, we can surely change it c/d

[12:55:35.0000] <wycats>
confirm/deny

[12:55:51.0000] <annevk>
wycats: folks might use it for the absolute URL test

[12:56:08.0000] <wycats>
it's so new we can get away with it

[12:56:23.0000] <wycats>
the fact that ppl are using that test should have been a hint to add a predicate ;)

[12:56:41.0000] <annevk>
wycats: I'm not sure if they are :-)

[12:56:51.0000] <wycats>
then we're safe to change it ;)

[12:56:56.0000] <wycats>
I hear FF has telemetry ;)

[12:58:00.0000] <nox>
What's wrong with the relativeURL() idea?

[12:58:36.0000] <wycats>
it makes sense to have a reflection of <a> in the URL spec

[12:58:43.0000] <nox>
Why?

[12:58:47.0000] <wycats>
O_o

[12:58:51.0000] <wycats>
new URL is fine, so is URL.platform()

[12:58:56.0000] <nox>
Should the URL href setter behave like on <a> too?

[12:59:05.0000] <wycats>
nox: because having to build everything up from primitives all the time is extremely annoying?

[12:59:09.0000] <caitp>
how many methods are you shoving into this thing

[12:59:11.0000] <wycats>
nox: no, you only need one

[12:59:14.0000] <wycats>
wut

[12:59:21.0000] <wycats>
do you even EWM?

[12:59:28.0000] <nox>
What?

[12:59:41.0000] <annevk>
wycats: well, I was trying, but now you want a dependency on <base>

[12:59:47.0000] <wycats>
https://extensiblewebmanifesto.org/

[12:59:55.0000] <wycats>
annevk: I think URL.platform() is a good solution

[12:59:58.0000] <annevk>
wycats: which just o_O (but bigger O) me

[13:00:17.0000] <wycats>
the point of EWM is not to make everyone rebuild the whole platform all the time

[13:00:22.0000] <caitp>
mr. dalton can always publish lodash-url.js if the *.relativeURL() idea doesn't work out

[13:00:23.0000] <wycats>
it's to give you the primitives the platform uses in layers

[13:00:37.0000] <nox>
Sure, but the URL object already seem to have a different purpose than the others implementors of URLUtils.

[13:00:52.0000] <annevk>
wycats: this object that is returned, would it also continue to observe the base URL if you change any of its properties? As <a> does?

[13:01:05.0000] <annevk>
wycats: which is rather magical (imo) behavior

[13:01:11.0000] <nox>
For example, the other implementors never return failure in the href setter, URL does.

[13:01:27.0000] <annevk>
wycats: and change whenever <base> changes? As <a> does?

[13:01:28.0000] <wycats>
you're taking me too literally, and nitpicking

[13:01:40.0000] <wycats>
annevk: unsure about that one

[13:01:47.0000] <nox>
Nitpicking about specs sounds on point.

[13:01:48.0000] <annevk>
wycats: I'm just curious

[13:01:58.0000] <wycats>
annevk: I think maybe yes if you .platform()

[13:02:05.0000] <wycats>
but via a host hook

[13:02:08.0000] <wycats>
the spec doesn't have to know

[13:02:22.0000] <wycats>
but no is also ok

[13:02:32.0000] <annevk>
wycats: well it gets rather complicated, since for DOM/HTML we need specific <base> changed notifications

[13:02:37.0000] <wycats>
but having to do a bunch of busywork to detect relative URLs is annoying

[13:02:51.0000] <annevk>
wycats: so you need to be able to get a base, and you need to take action when it changes

[13:02:58.0000] <wycats>
yeah

[13:03:02.0000] <wycats>
it's not critical

[13:03:11.0000] <wycats>
I don't literally mean it's the <a> tag

[13:03:16.0000] <nox>
Just don't detect them, and add a method on URLUtils that resolves a string against its url and returns a new URL.

[13:03:47.0000] <wycats>
what I basically mean is that it's: var div = document.createElement("div"); div.innerHTML = `<a href="${url}"></a>`; div.firstChild.href

[13:04:00.0000] <wycats>
that isn't live updated

[13:04:05.0000] <wycats>
but it does respect base

[13:06:26.0000] <annevk>
wycats: seems fairly reasonable; could even have URL.host(relativeURL) that varies per host

[13:06:33.0000] <wycats>
yeah

[13:06:39.0000] <wycats>
that's what I meant re: platform

[13:06:40.0000] <wycats>
host seems fine

[13:06:41.0000] <annevk>
wycats: and it's up to hosts to provide that method if they want to

[13:06:56.0000] <annevk>
wycats: and if URL ever becomes ES-ified it would likely not have .host()

[13:06:59.0000] <wycats>
annevk: yeah

[13:07:01.0000] <wycats>
annevk: right

[13:07:15.0000] <wycats>
although if node wants it we might specify it as a hook with some basic requirements

[13:07:26.0000] <annevk>
wycats: sure

[13:17:21.0000] <TabAtkins>
slightlyoff: No, pulling in global state does invalidate purity.

[13:37:34.0000] <wycats>
what does purity have to do with anything?

[13:42:23.0000] <TabAtkins>
wycats: I'm just correcting Alex. Pure functions are easy to reason about, and purity *does* require no connection to mutable global state.

[13:42:33.0000] <wycats>
yes, can confirm

[13:42:46.0000] <slightlyoff>
your window location isn't mutable

[13:42:58.0000] <slightlyoff>
(for the purposes of a base URL)

[13:43:03.0000] <TabAtkins>
Yes it is!

[13:43:09.0000] <slightlyoff>
it might as well be an environment variable

[13:43:13.0000] <TabAtkins>
replaceState()

[13:43:20.0000] <wycats>
it basically is an environment variable :P

[13:43:37.0000] <slightlyoff>
so now you have a design decision: would you use the original to preserve "purity"?

[13:44:12.0000] <TabAtkins>
...no, you use *neither* to preserve purity, *because it's global mutable state, and error-prone to depend on when you're not expecting it*.

[13:44:33.0000] <TabAtkins>
And window.location isn't even the thing that <a>.href works on.

[13:45:00.0000] <slightlyoff>
so we just covered why at least one of those statements is suspect

[13:45:04.0000] <TabAtkins>
There's no particular reason to assume that a random URL used in a script *intends* to pay attention to a <base> element on the page.

[13:45:15.0000] <slightlyoff>
and symmetry with <a>.href is interesting!

[13:46:06.0000] <TabAtkins>
The <a>.href behavior is almost certainly accidental, and I'd be completely unsurprised if it broke some pages accidentally and people had to work around it.

[13:46:25.0000] <TabAtkins>
(It's clearly intentional for <a>; it's accidental for the general "parse a url" behavior.)

[13:49:24.0000] <TabAtkins>
There's just so many contexts within the web platform that are totally reasonable to resolve a url against, that people work with every day.  I don't think there's any answer that is *sufficiently likely to be correct* that it can be set as the default.

[13:50:24.0000] <TabAtkins>
(I'm not all for purity in all cases; it's totally fine for, like, us to invent element constructors that imply a connection to the current script's document.  But that's almost certain to be right.)

[14:32:54.0000] <MikeSmith>
Domenic: http://stackoverflow.com/questions/25794905/why-does-set-e-true-false-true-not-exit

[14:33:07.0000] <MikeSmith>
"Why does set -e; true && false && true not exit?"

[14:33:29.0000] <MikeSmith>
I remember now running into this before

[14:33:58.0000] <MikeSmith>
it's by design

[14:34:34.0000] <MikeSmith>
set -e is supposed to be only for "uncaught" exceptions

[14:34:43.0000] <Domenic>
Ah...

[14:34:53.0000] <Domenic>
So use less &&s and more if, I guess?

[14:35:15.0000] <MikeSmith>
maybe

[14:35:25.0000] <MikeSmith>
or just switch back to  || exit 1

[14:35:54.0000] <MikeSmith>
which is ugly but shell scripts are fundamentally ugly anyway

[14:36:01.0000] <Domenic>
yeah

[14:36:09.0000] <Domenic>
yet somehow nothing is as good

[14:36:33.0000] <MikeSmith>
"worse is better"

[14:36:35.0000] <Domenic>
I once tried to rewrite https://github.com/whatwg/streams/blob/master/deploy.sh in Node.js. Got like 10 lines in before I realized this was not going to be fun.

[14:36:54.0000] <MikeSmith>
/me looks

[14:37:13.0000] <MikeSmith>
yeah

[14:37:46.0000] <MikeSmith>
I'm the same way with existing makefiles I have that I've tried to port to other task runners

[14:38:11.0000] <MikeSmith>
always reach the point of "just ain't gonna happen"

[14:38:47.0000] <MikeSmith>
I guess it's just the fact that the shell lets you do pretty much anything

[14:38:56.0000] <MikeSmith>
and other task runners really don't

[14:39:51.0000] <MikeSmith>
and makefiles are just ways to do anything you want with the shell as part of a build

[14:41:00.0000] <MikeSmith>
anyway I guess we should leave it alone for a bit and let some actual other users help find where the odd failures are

[14:41:21.0000] <MikeSmith>
this is not major stuff anyway, as far as making it easier to run and use

[14:41:46.0000] <MikeSmith>
the major thing I would still hope we can fix soon is the XML::Parser install requirement

[14:41:53.0000] <MikeSmith>
because that is just harsh

[14:42:28.0000] <Domenic>
yes agreed

[14:42:36.0000] <Domenic>
I wonder if python comes with xml parser by default

[14:42:48.0000] <MikeSmith>
yeah I think it does

[14:42:55.0000] <MikeSmith>
bindings to libxml2

[14:43:08.0000] <Domenic>
is libxml2 installed by default though

[14:43:08.0000] <MikeSmith>
gsnedders or maybe even TabAtkins would know better

[14:43:14.0000] <MikeSmith>
oh

[14:43:24.0000] <MikeSmith>
hmm, yeah, maybe not

[14:44:48.0000] <MikeSmith>
I think for now we could be OK just putting the cldr.inc file on whatwg.org somewhere and just manually re-generating/updating it when the upstream Unicode stuff changes

[14:45:09.0000] <MikeSmith>
either that or like I mentioned we could just check it into the repo

[14:45:26.0000] <MikeSmith>
I was surprised to see that it's only 25K

[14:46:05.0000] <Domenic>
i mean we *could* set up another build server endpoint like we did with wattsi

[14:46:33.0000] <MikeSmith>
yeah but it might be overkill for this, to rebuild it each time for each user

[14:46:49.0000] <tantek>
/me tries to read scrollback

[14:46:53.0000] <MikeSmith>
not a good use of bandwith I think

[14:47:03.0000] <MikeSmith>
the back-and-forth

[14:47:09.0000] <Domenic>
maybe

[14:47:31.0000] <MikeSmith>
it is worth if for the wattsi case, clearly

[14:47:42.0000] <MikeSmith>
hola tantek

[14:47:55.0000] <MikeSmith>
we talking about the build script for the HTML spec

[14:48:27.0000] <tantek>
yay spec plumbing

[14:48:35.0000] <tantek>
/me bows to the hardwork y'all put into that.

[14:50:28.0000] <gsnedders>
Domenic: there's multiple xml parsers!

[14:50:29.0000] <MikeSmith>
yeah it's fun to write stuff to try to make things as easy as possible for other people

[14:51:12.0000] <gsnedders>
Domenic: https://docs.python.org/3/library/xml.html#module-xml

[14:52:26.0000] <MikeSmith>
/me admires Domenic's relentlesseness towards clearing away as many hurdles as possible for others

[14:52:59.0000] <Domenic>
:) you did most of the hard work on this one

[14:53:39.0000] <MikeSmith>
anyway for now I think I'll instead try to spend my free time tonight/tomorrow making a couple actual patches/contributions/PRs to the spec

[14:53:59.0000] <MikeSmith>
get some of the remaining low-hanging fruit picked

[14:54:13.0000] <Domenic>
gsnedders: well this is just a scary page full of scary things.

[14:54:54.0000] <Domenic>
I guess I should go down to the Apple store and run some tests on clean macs to see if any of these python xml things work out of the box

[14:54:56.0000] <gsnedders>
Domenic: you want either xml.etree.cElementTree or lxml (not in stdlib)

[14:55:22.0000] <MikeSmith>
eventually I guess we're going to run out of the low-hanging fruit and it'll be like waking up with a bad hangover, staring at the list of remaining bugzilla bugs

[14:55:25.0000] <gsnedders>
Domenic: unless you need a streaming parser

[14:55:41.0000] <Domenic>
gsnedders:  xml.etree.cElementTree sounds reasonable

[14:55:42.0000] <MikeSmith>
gsnedders: what streaming parser is there?

[14:57:27.0000] <MikeSmith>
gsnedders: incidentally, do you know how I can pass namespaceHTMLElements=False to the lxml html5parser?

[14:57:57.0000] <gsnedders>
MikeSmith: xml.sax or xml.parsers.expat

[14:58:04.0000] <MikeSmith>
ah ok

[14:58:08.0000] <gsnedders>
MikeSmith: I suspect it should work, I don't know

[14:58:14.0000] <gsnedders>
MikeSmith: lxml has a streaming one too

[14:58:54.0000] <MikeSmith>
yeah I was thinking HTML parser and had forgotten that the subject at hand is XML parsing

[15:00:17.0000] <MikeSmith>
gsnedders: about namespaceHTMLElements=False, in that bug he makes it sound like it's sorta obvious how to do it. but I don't see where it's exposed

[15:00:24.0000] <MikeSmith>
I guess I need to read the docs more

[15:01:39.0000] <gsnedders>
MikeSmith: gimme a few mins

[15:01:40.0000] <MikeSmith>
that guy is somewhat Ms2ger/annevk-ish with regard to the brevity and enigmatic nature of some of his responses

[15:01:43.0000] <MikeSmith>
hai

[15:01:51.0000] <gsnedders>
oh, he's like that IRL too :)

[15:02:08.0000] <MikeSmith>
ah you met him

[15:02:31.0000] <MikeSmith>
would be nice to meet him some time. I guess he's in Germany somewhere?

[15:04:24.0000] <MikeSmith>
/me suspects that Domenic is thinking about re-writing one of Hixie's perl scripts in python, hands him a box of tissue in preparation for the tears he's going to need to spend time wiping away

[15:05:09.0000] <Domenic>
yepppp

[15:06:38.0000] <gsnedders>
MikeSmith: yeah, forget where

[15:06:45.0000] <gsnedders>
MikeSmith: often at EuroPython

[15:09:52.0000] <MikeSmith>
y'all #whatwg python mavens make me want to be a better python hacker. I actually really like writing in python more than any other language, but I do very little of it

[15:29:55.0000] <TabAtkins>
libxml2 is *not* installed by default. >_<

[15:30:20.0000] <TabAtkins>
But anyone willing to install Bikeshed has it. ^_^

[15:31:27.0000] <TabAtkins>
MikeSmith: Like `doc = html5lib.parse(text, treebuilder='lxml', namespaceHTMLElements=False)`

[15:32:23.0000] <MikeSmith>
TabAtkins: I mean lxml interface to it

[15:32:45.0000] <TabAtkins>
Oh, dunno how html5lib invokes the lxml parser.

[15:32:52.0000] <MikeSmith>
http://lxml.de/html5parser.html

[15:33:45.0000] <MikeSmith>
yeah I know how (I even made a PR to patch the lxml sources) but I just don't see where it exposes it

[15:36:36.0000] <MikeSmith>
/me resorts to re-reading teh sources

[16:18:13.0000] <MikeSmith>
gsnedders: ↓

[16:18:17.0000] <MikeSmith>
$ cat test.py

[16:18:18.0000] <MikeSmith>
from lxml.html import html5parser, tostring

[16:18:18.0000] <MikeSmith>
parser = html5parser.HTMLParser(namespaceHTMLElements=False)

[16:18:18.0000] <MikeSmith>
print tostring(html5parser.fromstring("<html>", parser))

[16:18:36.0000] <MikeSmith>
$ python test.py

[16:18:37.0000] <MikeSmith>
<html:html xmlns:html="http://www.w3.org/1999/xhtml"><html:head></html:head><html:body></html:body></html:html>

[16:39:19.0000] <gsnedders>
MikeSmith: hmm, okay, maybe not

[16:40:17.0000] <gsnedders>
MikeSmith: that should work, I thought?

[16:40:34.0000] <gsnedders>
and it looks like it should work

[16:40:51.0000] <gsnedders>
given **kwargs are passed through

[16:45:50.0000] <Krinkle>
Is there a simple and reliable way to defer code execution until after window-onload if you don't know whether that event has happened already?

[16:46:01.0000] <TabAtkins>
MikeSmith: I'd think that would work, yeah. Confusing.

[16:46:21.0000] <Krinkle>
I can't for the life of me figure it out, short of polling performance.timing.loadEventEnd

[16:46:24.0000] <TabAtkins>
Krinkle: In the ideal future, we'll have a .ready() promise on document that reflects the onload event.

[16:46:57.0000] <TabAtkins>
This is why events are not the correct abstraction for single-occurence things.

[16:47:04.0000] <Krinkle>
yeah

[16:47:19.0000] <Krinkle>
I want jQuery document.ready for window.onload

[16:47:21.0000] <Krinkle>
basically

[16:48:57.0000] <Krinkle>
I would settle for a simple way to know whether it's "safe" to add an event listener to window.onload (e.g. has it already started), and then know to either schedule or inoke callback now

[16:51:27.0000] <Krinkle>
I just realised today that a fair number of Navigation Timing metrics werent' being delivered from browser clients using Wikipedia because the event logging code used window.onload

[16:51:33.0000] <Krinkle>
which sometimes had already happened :facepalm:


2015-09-10
[17:01:10.0000] <TabAtkins>
Domenic: Any progress on document.ready promise?

[17:37:30.0000] <Domenic>
TabAtkins: open an issue on html so we don't forget? Should be easy now that we can edit the spec, just need to line up a few implementers.

[18:38:00.0000] <MikeSmith>
gsnedders: yeah there seems to be a bug in html5lib that's causing it to ignore namespaceHTMLElements=False

[18:41:40.0000] <MikeSmith>
gsnedders: tossing a sys.stderr.write("namespaceHTMLElements is %s \n" % str(namespaceHTMLElements)) into the HTMLParser constructor I see:

[18:41:53.0000] <MikeSmith>
namespaceHTMLElements is True

[18:41:55.0000] <MikeSmith>
namespaceHTMLElements is False

[18:45:14.0000] <MikeSmith>
and if I change the signature of the constructor to have namespaceHTMLElements=False instead of True, then it does work as expected (that is, html element goes into void namespace, and I finally get un-namespaced output when I serialize)

[19:05:38.0000] <gsnedders>
MikeSmith: huh?

[19:05:50.0000] <gsnedders>
MikeSmith: minimal TC with just html5lib and no lxml, plz?

[20:00:35.0000] <MikeSmith>
gsnedders: Hai

[20:07:50.0000] <annevk>
Domenic: I updated the ruby parser commit and updated the commit message too

[20:19:18.0000] <annevk>
Heh, whatwg/html is already more popular than whatwg/fetch

[20:19:25.0000] <annevk>
whatwg/streams is still miles ahead though

[20:52:32.0000] <gsnedders>
hmm, there's no way to use idlharness.js to check document.all, because of the typeof checks

[21:41:31.0000] <MikeSmith>
gsnedders: you sure?

[21:41:39.0000] <MikeSmith>
ah document.all

[21:45:03.0000] <annevk>
/me wonders how familiar jgraham is with Fetch and how well he remembers his navigate adventures

[21:49:00.0000] <annevk>
MikeSmith: I'm a bit hesitant to update my local https://github.com/whatwg/html-build copy as it's unclear from the README.md how to preserve my local whatwg/html copy

[21:49:17.0000] <annevk>
MikeSmith: shall I file an issue?

[21:51:28.0000] <MikeSmith>
yeah

[21:51:47.0000] <MikeSmith>
it's not going to overwrite your existing repo though

[21:52:15.0000] <MikeSmith>
the only time it tries to clone the repo is if it doesn't find any existing one

[21:52:32.0000] <annevk>
MikeSmith: does it look for ../html?

[21:52:35.0000] <MikeSmith>
yeah

[21:52:40.0000] <MikeSmith>
only that

[21:52:42.0000] <annevk>
okay, so I guess I'm good then

[21:52:48.0000] <MikeSmith>
yes I think so

[21:53:25.0000] <annevk>
ah, I do need to clean up old files somehow

[21:54:18.0000] <MikeSmith>
also fwiw if it makes a clone it only ever clones it into a subdirectory of the directory the build.sh script is in; that is, into your html-build dir

[21:55:27.0000] <annevk>
Hmm, I wonder why git reset --hard doesn't remove all the local files that are now supposed to be elsewhere

[21:56:10.0000] <annevk>
Isn't that the way to get rid of all kinds of uncommitted resources and such?

[21:57:26.0000] <annevk>
Ah, git clean -fd

[21:57:56.0000] <annevk>
"OK, looked in the /Users/annevk/GH/html directory and found HTML source there..."

[21:58:00.0000] <annevk>
Going well so far

[21:58:56.0000] <annevk>
MikeSmith: <3 those messages

[21:59:04.0000] <MikeSmith>
heh

[21:59:13.0000] <MikeSmith>
a little human touch there

[21:59:50.0000] <annevk>
It still works :-)

[21:59:51.0000] <MikeSmith>
annevk: git clean -fdx is what I usually do, fwiw

[21:59:55.0000] <MikeSmith>
heh

[22:00:05.0000] <MikeSmith>
good ✌️

[22:00:11.0000] <annevk>
Hopefully I no longer I have the problem of html-build/source and html/source getting confused

[22:00:42.0000] <annevk>
MikeSmith: did you see 🖖?

[22:00:46.0000] <MikeSmith>
you will not have that problem

[22:00:50.0000] <MikeSmith>
oh man

[22:00:52.0000] <MikeSmith>
wow

[22:00:56.0000] <MikeSmith>
no, dinnet now

[22:01:04.0000] <MikeSmith>
hober gotta love tha one

[22:01:07.0000] <annevk>
Got it from hober

[22:01:10.0000] <MikeSmith>
hahah

[22:01:16.0000] <annevk>
(obv)

[22:01:20.0000] <MikeSmith>
yeah

[22:01:29.0000] <MikeSmith>
I miss hober

[22:01:44.0000] <MikeSmith>
haven't talked with him for quite a while

[22:01:54.0000] <terinjokes>
MikeSmith: i started to get into the habit of `git clean -fdx` after publishing packages to npm for 6 months with my .idea folder included

[22:02:45.0000] <MikeSmith>
terinjokes: yeah if you're going to clean, you should, you know, clean

[22:18:20.0000] <annevk>
MikeSmith: the commit contains "TODO Move the following comment to the README.md file after we review."

[22:35:37.0000] <MikeSmith>
ah yeah

[22:35:41.0000] <MikeSmith>
will do that

[22:35:55.0000] <MikeSmith>
thanks for catching that

[22:46:08.0000] <MikeSmith>
annevk: fwiw I would prefer that we follow a policy that nobody ever push their own PRs to master unreviewed, ever

[22:46:13.0000] <MikeSmith>
no matter how small

[22:46:31.0000] <MikeSmith>
both for the build script and the source

[22:47:25.0000] <annevk>
MikeSmith: you mean no changes ever?

[22:47:41.0000] <annevk>
MikeSmith: maybe that is the best for this specification

[22:47:45.0000] <MikeSmith>
I think that is ideal

[22:47:50.0000] <MikeSmith>
yeah for the spec at least for sure

[22:48:15.0000] <MikeSmith>
everybody make mistakes sometimes

[22:48:30.0000] <MikeSmith>
always better to have a 2nd pair of eyes

[22:48:47.0000] <MikeSmith>
sanity check, etc

[22:48:52.0000] <MikeSmith>
anyway, https://github.com/whatwg/html-build/pull/22

[22:49:14.0000] <annevk>
Yeah makes sense, given that most writing PRs haven't written the text doesn't help either

[22:49:39.0000] <annevk>
MikeSmith: so yeah, I saw that, r+, but I guess I should merge it?

[23:01:39.0000] <MikeSmith>
yes please

[23:38:30.0000] <SteveF_>
annevk: domenic: as pre hixies feedback on ARIA section update, have removed the whole section and updated PR

[23:39:02.0000] <MikeSmith>
hey SteveF_

[23:39:13.0000] <SteveF_>
hi

[23:39:54.0000] <MikeSmith>
I reckon Domenic and Hixie are away but annevk is here

[23:40:03.0000] <SteveF_>
OK

[23:44:30.0000] <annevk>
SteveF_: I guess it might still be good to <ref> the various ARIA specifications

[23:44:52.0000] <annevk>
SteveF_: or perhaps group them all under the [ARIA] banner?

[23:46:29.0000] <SteveF_>
annevk: I think it is worthwhile pointing implementers to the other specs, but seems like hixie didn't

[23:47:50.0000] <SteveF_>
annevk: " under the [ARIA] banner" where? also not all are ARIA specs notably HTML acc API spec

[23:49:08.0000] <annevk>
SteveF_: well, "This is redundant with the referenced specs." would no longer be true if we didn't reference anything, would it?

[23:49:39.0000] <SteveF_>
annevk: I could add the section back with the references

[23:49:59.0000] <SteveF_>
refernces only that is

[23:49:59.0000] <annevk>
SteveF_: I meant that the text keeps it <ref spec=ARIA> and that the references section includes the various specifications under that banner, similar to what is done for HTTP

[23:53:49.0000] <annevk>
SteveF_: and apologies for making this take so long, I was obviously not experienced enough to review that

[23:54:22.0000] <annevk>
SteveF_: still a bit early days trying to maintain HTML

[23:55:46.0000] <SteveF_>
annevk: no problem

[00:01:19.0000] <SteveF_>
annevk: have pushed update to ARIA section PR that just has very brief references to the 2 relevant specs

[00:02:24.0000] <SteveF_>
annevk: will wait to see how that goes down

[00:04:30.0000] <annevk>
SteveF_: did you intentionally leave the list of roles and list of aria-* attributes in source?

[00:05:18.0000] <SteveF_>
annevk: form the other section? I haven't looked at that bit yet thats as it was

[00:05:49.0000] <SteveF_>
annevk: not added or edited by me

[00:06:03.0000] <MikeSmith>
yeah I think we need to keep those

[00:06:20.0000] <MikeSmith>
I don't think there is a conflict in keeping them

[00:06:36.0000] <MikeSmith>
that section is not defining any requirements around them

[00:07:03.0000] <MikeSmith>
it's basically just stating that they exist and are a part of the language

[00:07:03.0000] <annevk>
It also has "The terms strong native semantics is used as defined in the ARIA specification. The term default implicit ARIA semantics has the same meaning as the term implicit WAI-ARIA semantics as used in the ARIA specification." which wouldn't really be relevant anymore

[00:07:18.0000] <MikeSmith>
hmm yeah

[00:07:21.0000] <SteveF_>
what i said previoulsy is I would do a PR at some point to update the links there as they currently point to ARIA 1.0

[00:08:54.0000] <SteveF_>
annevk: so should i remove "The terms strong native semantics is used as defined in the ARIA specification. The term default implicit ARIA semantics has the same meaning as the term implicit WAI-ARIA semantics as used in the ARIA specification."?

[00:09:59.0000] <annevk>
I'm not a 100% sure, but it seems like it

[00:10:46.0000] <SteveF_>
OK

[00:11:00.0000] <annevk>
I would prefer it if we reworked all of ARIA in a single commit in the end

[00:11:20.0000] <MikeSmith>
yes please

[00:11:26.0000] <MikeSmith>
squash

[00:11:28.0000] <annevk>
I can take care of squashing your work, but if you have any other changes planned please make them here I think

[00:11:53.0000] <annevk>
And then hopefully we can get Hixie to review when he wakes up and make this happen

[00:14:14.0000] <MikeSmith>
Edge team just changed srcdoc to "under review"

[00:14:16.0000] <MikeSmith>
https://dev.modern.ie/platform/status/iframesrcdocattribute/

[00:14:50.0000] <MikeSmith>
it was previously "no status"

[00:15:44.0000] <annevk>
srcdoc is one of the things that makes navigate complicated

[00:16:25.0000] <annevk>
I didn't realize this until today or so, but "navigate"'s input is "a new resource"

[00:16:39.0000] <annevk>
And that means much more than a URL

[00:23:19.0000] <SteveF_>
annevk: pushed update with that text removed and links to aria attributes updated to point to latest spec

[00:23:32.0000] <SteveF_>
annevk: so that should be it

[00:26:24.0000] <MikeSmith>
annevk: yeah that "navigate" stuff needs some attention

[00:27:09.0000] <annevk>
SteveF_: ta

[00:27:48.0000] <annevk>
SteveF_: almost 1% of line savings

[00:28:09.0000] <SteveF_>
annevk: is that good?

[00:29:09.0000] <annevk>
SteveF_: I think so, although it's somewhat sad to have a core part of HTML defined elsewhere

[00:33:17.0000] <SteveF_>
annevk: at least its defined somewhere :-)

[00:50:25.0000] <zcorpan>
Ms2ger: r? https://critic.hoppipolla.co.uk/r/5785

[01:06:49.0000] <nox>
Ms2ger: Of what?

[01:06:55.0000] <Ms2ger>
https://critic.hoppipolla.co.uk/r/5785

[01:14:45.0000] <annevk>
It seems to me that navigating back to an about:srcdoc document is not as well-defined as it should be

[01:15:09.0000] <annevk>
Or maybe I missed something and those cannot end up in session history anyway?

[01:15:16.0000] <annevk>
I didn't actually check that...

[01:16:07.0000] <nox>
Ms2ger: Oh, the tests fail because they are wrong?

[01:16:20.0000] <Ms2ger>
I dunno

[01:17:58.0000] <Ms2ger>
That's why I'm delegating :)

[01:18:30.0000] <nox>
The spec does reject most things in a frameset.

[01:18:43.0000] <annevk>
nox: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=29041 for context

[01:26:44.0000] <nox>
Ms2ger: LGTM

[01:54:04.0000] <jgraham>
annevk: I remember a little about navigation, but know very little about fetch

[01:57:16.0000] <annevk>
jgraham: I guess have to start from scratch then

[01:57:57.0000] <jgraham>
annevk: Wat are you trying to do?

[01:58:19.0000] <annevk>
jgraham: integrate the two

[01:58:57.0000] <Ms2ger>
Sounds like we should ship you plenty of hard liquor, then

[01:59:11.0000] <jgraham>
iirc the parts of navigation that actually fetch documents are super-handwavy at the moment

[01:59:31.0000] <jgraham>
"do some magic until you have some bytes"

[02:07:40.0000] <annevk>
Ms2ger: that might just make it worse :-)

[02:08:00.0000] <annevk>
Ms2ger: good tea is welcome though

[02:17:38.0000] <jgraham>
Speaking of tea…

[03:14:17.0000] <nox>
zcorpan: No problem.

[03:56:20.0000] <Ms2ger>
/me noticed http://blogs.opera.com/news/2015/09/opera-interns-share-their-stories/ had no Core interns

[04:13:26.0000] <MikeSmith>
annevk: http://stackoverflow.com/questions/32500073/request-header-field-access-control-allow-headers-is-not-allowed-by-itself-in-pr

[04:18:42.0000] <jgraham>
Ms2ger: That appears to be a subset of all the interns though

[04:21:45.0000] <MikeSmith>
about python troubleshooting, how do you all normally troubleshoot code where it's using multiple libs and trying to figure out where a problem might be?

[04:22:04.0000] <MikeSmith>
gdb?

[04:22:29.0000] <MikeSmith>
and/or is there some way to just dump a stack trace?

[04:23:11.0000] <jgraham>
MikeSmith: What kind of problem?

[04:23:40.0000] <jgraham>
YOu can get a stacktrace from within python using the traceback module

[04:24:00.0000] <MikeSmith>
k

[04:24:02.0000] <jgraham>
pdb is also reasonable if you aren't running with multiple threads and things

[04:24:11.0000] <MikeSmith>
ah yeah

[04:24:16.0000] <jgraham>
If you have something super-complicated using gdb makes sense

[04:24:20.0000] <MikeSmith>
I recall use that before

[04:24:27.0000] <MikeSmith>
it's not super-complicated

[04:24:30.0000] <MikeSmith>
echo "<p>" | python -c "from sys import stdin; from lxml.html import html5parser as h5, tostring; print tostring(h5.parse(stdin, h5.HTMLParser(namespaceHTMLElements=False)))"

[04:24:36.0000] <jgraham>
e.g. I use gdb when I'm trying to figure out deadlocks

[04:24:44.0000] <MikeSmith>
<html:html xmlns:html="http://www.w3.org/1999/xhtml"><html:head></html:head><html:body><html:p>

[04:24:47.0000] <MikeSmith>
</html:p></html:body></html:html>

[04:25:03.0000] <MikeSmith>
yeah this problem is not complex

[04:30:37.0000] <Ms2ger>
It involves an HTML parser, it is complex :)

[04:35:34.0000] <MikeSmith>
heh

[04:56:48.0000] <MikeSmith>
ok I reckon I have it figured out

[04:58:02.0000] <MikeSmith>
well, a guess at least

[05:11:55.0000] <annevk>
MikeSmith: tried to answer

[05:12:10.0000] <MikeSmith>
cool

[05:57:24.0000] <MikeSmith>
the Push API has landed in Gecko?

[05:57:27.0000] <MikeSmith>
https://bugzilla.mozilla.org/show_bug.cgi?id=1038811

[05:57:32.0000] <MikeSmith>
resolved=fix

[05:57:53.0000] <MikeSmith>
wondering when it will ship

[06:23:56.0000] <gsnedders>
Ms2ger: well of course it didn't, Core hasn't existed for years!

[06:24:50.0000] <Ms2ger>
Can I bug you for reviews already?

[06:38:44.0000] <Ms2ger>
jgraham, annevk, you mentioned tea? https://historyofloveblog.wordpress.com/2013/10/10/can-drinking-tea-turn-you-into-a-whore/

[06:41:02.0000] <annevk>
Ms2ger: I guess the rest of the world picked up on our channel topic at some point

[06:51:50.0000] <wanderview>
annevk: you around?

[06:51:59.0000] <annevk>
wanderview: c

[06:52:16.0000] <wanderview>
annevk: regarding this: https://github.com/whatwg/html/issues/95#issuecomment-138653119

[06:52:52.0000] <wanderview>
annevk: as far as I can tell, the spec says to return the Response provided to respondWith() as the result of the fetch algorithm

[06:53:14.0000] <wanderview>
which suggests if the Response has a different url from the original Request, then that will be visible to script

[06:53:26.0000] <wanderview>
annevk: sorry if there is somewhere that says to override the Response.url with the original Request.url.... I can't find it

[06:53:28.0000] <annevk>
wanderview: step 15 of https://fetch.spec.whatwg.org/#main-fetch

[06:54:06.0000] <wanderview>
ah

[06:54:56.0000] <wanderview>
annevk: I see... and this works because 30x redirects are appending to the *request* url list, not the response list

[06:56:43.0000] <annevk>
wanderview: they can't append to the response list

[06:56:47.0000] <annevk>
wanderview: they are a response

[06:57:03.0000] <wanderview>
annevk: yea, I just think necko is modeled differently

[06:57:29.0000] <annevk>
ah, shucks

[06:59:46.0000] <wanderview>
annevk: the good news is my original concept of what SW+fetch was supposed to is correct... I just misread the spec when trying to prove it to ehsan

[07:03:05.0000] <annevk>
wanderview: have to bring your A game to ehsan

[07:03:46.0000] <annevk>
/me finds out that more headers are subject to Referer than just Referer!

[07:04:08.0000] <annevk>
Well, subject to the referrer policy...

[07:07:23.0000] <wanderview>
annevk: I'm going to CC you on this email if thats ok

[07:07:32.0000] <annevk>
wanderview: sure

[07:10:11.0000] <wanderview>
annevk: have you thought about how you will spec the opaque tainting?

[07:10:49.0000] <wanderview>
the opaque tainting for images written to canvas

[07:16:39.0000] <annevk>
wanderview: I haven't settled on something definitive yet I think, at the moment I'm just trying to convert the existing language and adding some new concepts along the way to help with that

[07:16:55.0000] <annevk>
wanderview: I hope that once I'm through I can figure out something that's a bit more coherent

[07:17:45.0000] <annevk>
wanderview: but in general it's as we discussed I think; basic/cors/default is "safe", other types are unsafe

[07:18:26.0000] <wanderview>
annevk: yea, I was more wondering how it would be tracked... just a boolean flag... or an origin that is compared

[07:19:38.0000] <annevk>
wanderview: ah I think I discussed that with bz and Hixie at some point and we decided boolean was fine

[07:20:04.0000] <annevk>
wanderview: that once you're secure it's okay, even if you then end up leaking it with your public suffix friends

[07:25:10.0000] <wanderview>
annevk: yea... I think we felt we needed the final URL fully propagated before we had some of the recent spec changes implemented... if you look at my email it seems we are safe and a boolean should work

[07:25:11.0000] <wanderview>
I think

[07:25:17.0000] <wanderview>
annevk: ehsan may disagree

[07:28:35.0000] <annevk>
wanderview: yeah the security really doesn't depend on URLs

[07:28:42.0000] <annevk>
wanderview: it's just tainting

[07:28:59.0000] <annevk>
wanderview: and once you're tainted you can't untaint

[09:02:06.0000] <Domenic>
jkdflsajdf git troubles

[09:02:35.0000] <Domenic>
fffrig annevk can you re-push that commit i killed it accidentally

[09:03:50.0000] <annevk>
Domenic: c6d4dda..8d1c8af  ruby -> ruby

[09:03:59.0000] <annevk>
(aka done)

[09:04:03.0000] <annevk>
(also rebased)

[09:04:48.0000] <Domenic>
ok cool. github wasn't smart enough to re-associate with the pr oh well

[09:05:19.0000] <annevk>
Domenic: hmm weird, always works for me these days

[09:05:51.0000] <annevk>
Domenic: hmm you didn't push?

[09:05:57.0000] <Domenic>
annevk: I was experimenting with my local script and effed things up and force-pushed to the ruby branch with zero commits. which auto-closed the PR. when you re-added a commit it wasn't smart enough to re-open the PR.

[09:06:10.0000] <annevk>
Domenic: oh

[09:06:38.0000] <annevk>
perhaps edit the commit message then to say Close #101: ...?

[09:07:30.0000] <Ms2ger>
/me tends to put (fixes #nnn) at the ned

[09:07:31.0000] <Ms2ger>
end

[09:08:56.0000] <Domenic>
Oh I think I know the problem

[09:09:01.0000] <Domenic>
I was using my new checkout from the build script

[09:09:05.0000] <Domenic>
Which doesn't have the full history

[09:09:19.0000] <Domenic>
which makes git confused about remote branches that are based on top of previous commits

[09:09:19.0000] <annevk>
I gotta go for a bit

[09:09:21.0000] <Domenic>
(like ruby used to be)

[09:09:32.0000] <Domenic>
OK, it'll be merged with no problems by the time you get back, promise

[09:28:07.0000] <annevk>
Domenic: so the problem with not associating either through GitHub's purple thingie or an explicit "Close #n:" is that someone browsing the commit logs has no way to find the rationale

[09:28:26.0000] <Domenic>
annevk: oh, I see :(

[09:28:46.0000] <Domenic>
I was like ... but 101 is already accidentally closed...

[09:28:50.0000] <annevk>
Domenic: so I think we should maybe make that part of the policy, that you either have a clean merge or edit the commit message

[09:29:15.0000] <Domenic>
annevk: OK. I find it a bit weird for PRs to close themselves but your reasoning is more compelling.

[09:29:34.0000] <Domenic>
What some projects do is standardize on fields like PR URL: ...

[09:29:53.0000] <Domenic>
e.g. browse the commits at https://github.com/nodejs/node/commits/master

[09:46:20.0000] <annevk>
That seems fine too

[09:47:58.0000] <Domenic>
Is the ARIA PR still waiting on something?

[09:49:20.0000] <annevk>
Domenic: Hixie

[09:49:35.0000] <Domenic>
It looks like the ASCII fish example is still missing

[09:49:57.0000] <annevk>
Domenic: that seems to be in the referenced draft...

[09:50:06.0000] <Domenic>
I guess we shouldn't duplicate it

[09:50:07.0000] <annevk>
Domenic: Steve added it back in, but dropped it after Hixie's comments

[09:50:11.0000] <Domenic>
OK

[09:58:17.0000] <annevk>
/me added the kitchen sink to the header of https://twitter.com/htmlstandard

[10:07:08.0000] <annevk>
I'll merge ARIA

[10:14:03.0000] <annevk>
Getting some errors from the build script...

[10:28:29.0000] <annevk>
The errors were from the W3C Bugzilla cross-referencing btw

[10:28:40.0000] <annevk>
Closing the bugs seems to have helped...

[10:30:13.0000] <Domenic>
heh

[10:30:25.0000] <Domenic>
yeah I noticed MikeSmith removing some URLs from bugs presumably for similar reasons

[10:30:39.0000] <Domenic>
I need to fix https://github.com/whatwg/html-build/issues/21

[11:24:11.0000] <Domenic>
beverloo: long shot but do you have a SVG of http://peter.sh/experiments/asynchronous-and-deferred-javascript-execution-explained/

[11:37:52.0000] <hober>
MikeSmith: awwwwh, I miss you too Mike.

[12:10:51.0000] <wanderview>
annevk: Domenic: have we figured out how to handle variable length uploads with fetch streams integration? mcmanus tells me that will not work for http1 since it needs an accurate content-length on the upload

[12:11:21.0000] <Domenic>
wanderview: content-encoding chunked, right?

[12:11:41.0000] <Domenic>
wanderview: I thought all streaming uploads would be CE: chunked

[12:11:49.0000] <wanderview>
Domenic: http1.1 supports chunked, but http1 does not... and we cannot tell if the server supports 1.1 until after we send the request

[12:12:06.0000] <Domenic>
wanderview: i guess fetch stream uploads don't work with http 1.0 then

[12:12:24.0000] <wanderview>
Domenic: we're not tackling this in the spec yet, right?

[12:12:40.0000] <Domenic>
wanderview: no, no uploads yet. Q4 is yhirano_'s plan

[12:13:13.0000] <wanderview>
Domenic: well, FYI about this issue then... I ran into it a bit prematurely because I was trying to lay some groundwork in infrastructure while fixing another bug

[12:13:37.0000] <Domenic>
yeah, good to know :-S

[12:14:45.0000] <wanderview>
Domenic: is there an issue or somewhere I should note this?

[12:15:13.0000] <Domenic>
wanderview: fetch-with-streams has a whole label for upload, yeah, would be good.

[12:15:23.0000] <wanderview>
ok, thanks

[12:35:00.0000] <wanderview>
https://github.com/yutakahirano/fetch-with-streams/issues/57

[12:48:14.0000] <MikeSmith>
TabAtkins: fyi http://stackoverflow.com/questions/32493442/html-whitespace-spaces-before-and-after-br

[12:50:15.0000] <MikeSmith>
Domenic: yeah, I removed the URLs from those bugs because with the source on the ARIA branch, the presence of them was an error, so rightly the merge of the branch shouldn't happen until those errors were fixed

[12:50:31.0000] <MikeSmith>
this is another thing we need to document

[12:51:39.0000] <MikeSmith>
the timing of when to remove the URLs is a gray era I guess. But basically, they shouldn't be removed until there's agreement to merge the branch

[12:53:13.0000] <MikeSmith>
also I think someone reviewing the branch needs to take also responsibility for actually closing the bugs (or moving their components), if it turns out that after the changes, the bug is no longer relevant or has been resolved by the changes on the branch

[12:54:12.0000] <annevk>
wanderview: I guess it would just fail for HTTP/1.0 then

[12:54:26.0000] <annevk>
wanderview: is that problematic?

[12:54:54.0000] <wanderview>
annevk: if the js script expects to do an infinite upload stream... what will happen?

[12:55:08.0000] <wanderview>
get an error code immediately when it sees the chunked setting?

[12:55:12.0000] <wanderview>
when the server sees

[12:55:22.0000] <wanderview>
or does the server wait for the entire body to finish before sending an error code?

[12:55:27.0000] <wanderview>
I expect there are server bugs here

[13:00:16.0000] <annevk>
wanderview: I have no idea

[13:00:32.0000] <annevk>
wanderview: servers are rather broken, typically

[13:00:37.0000] <wanderview>
annevk: yea, just saying we should test some servers and see what they do

[13:00:47.0000] <wanderview>
before creating a footgun to easily OOM the browser

[13:00:58.0000] <wanderview>
because servers do something different than we expect

[13:01:18.0000] <wanderview>
annevk: in fairness, browsers are rather broken typically too

[13:05:33.0000] <MikeSmith>
annevk: the https://twitter.com/htmlstandard image is perfect🖖

[13:20:56.0000] <caitp>
hah

[13:22:23.0000] <Domenic>
someone test http://jsbin.com/xelixaqaru/edit?html,output in Safari for me? what type of error is in your console?

[13:22:34.0000] <MikeSmith>
Domenic: looking now

[13:23:08.0000] <MikeSmith>
7TypeError

[13:23:12.0000] <Domenic>
perfect

[13:24:27.0000] <MikeSmith>
Domenic: btw I think adopting a PR URL: convention would be good

[13:24:42.0000] <MikeSmith>
with the nit that it could just as well but PR:

[13:24:57.0000] <MikeSmith>
(without the URL part)

[13:25:16.0000] <MikeSmith>
because it's always going to be a URL

[13:25:53.0000] <MikeSmith>
*could just as well be just "PR:"

[13:26:03.0000] <Domenic>
Heh yes

[13:40:10.0000] <Domenic>
MikeSmith: regarding https://github.com/whatwg/html-build/issues/21#issuecomment-139366175, should we just treat any output from wattsi as an error, and return the error text instead of the zip file?

[13:40:49.0000] <TabAtkins>
MikeSmith: Thanks for the heads up on that SO thread. I've sent email to the list about it. ^_^

[13:45:04.0000] <MikeSmith>
TabAtkins: cool

[13:45:42.0000] <MikeSmith>
TabAtkins: I really wish you were the one editing that spec

[13:45:50.0000] <MikeSmith>
but you can't do everything, I guess

[13:56:57.0000] <TabAtkins>
Unfortunately.

[15:22:48.0000] <MikeSmith>
TabAtkins: the CSS WG should put a clear disclaimer on those other specs

[15:23:01.0000] <TabAtkins>
What other specs?

[15:23:11.0000] <MikeSmith>
Warning: This spec was NOT written by Tab Atkins

[15:23:13.0000] <MikeSmith>
I mean

[15:23:44.0000] <MikeSmith>
I'm only half-joking

[15:25:14.0000] <MikeSmith>
because seriously if I go to look at a CSS WG spec and don't see that you have been one of the people working on it, I am not always super-confident about the rigor/precision/etc of what I may find inside

[16:24:15.0000] <gsnedders>
y'know, having booked tickets and hotels for TPAC, I probably ought, like, join a W3C WG.

[16:24:15.0000] <TabAtkins>
<3

[16:24:28.0000] <gsnedders>
Given I'm currently on, um, none.

[16:26:10.0000] <tantek>
gsnedders, aren't you a member of the WHATWG CG?

[16:26:21.0000] <tantek>
perhaps find an IG or two to join as well.

[16:30:09.0000] <Domenic>
Yay the canvas PR is here. I love new features.

[16:31:10.0000] <gsnedders>
tantek: I should rejoin the CSS WG too, given I'm probably gonna start kicking around there again too

[16:31:26.0000] <gsnedders>
tantek: given the whole habit of giving ex-members IE status

[16:32:44.0000] <tantek>
doesn't hurt to ask the chairs

[16:34:19.0000] <gsnedders>
MikeSmith: can you prod someone so my invited expert application gets accepted? AFAICT nobody gets notified given I already had one on file from when I was an invited expert before?

[16:42:55.0000] <ccardona-work>
Where is the TPAC this year?

[16:43:19.0000] <ccardona-work>
Japan?

[16:47:21.0000] <gsnedders>
ccardona-work: yeah, in Sapporo

[16:47:36.0000] <ccardona-work>
that sounds exciting.

[16:47:56.0000] <ccardona-work>
i realize now how fortunate I was that it happened in San Jose a few years back and I was able to go.


2015-09-11
[17:02:08.0000] <jamesr___>
sapporo sounds way more interesting than san jose to me

[17:02:26.0000] <gsnedders>
To be fair, most places sound more interesting than San Jose

[17:14:27.0000] <ccardona-work>
i didn’t say that it San Jose was more interesting. I said that i was fortunate that at the time when I was studying web development in santa cruz the TPAC happened to be in San Jose which allowed Google to pay for me to go.

[17:14:57.0000] <ccardona-work>
i was able to meet a bunch of the WHATWG crew and i wouldn’t have been able to do that if it would have been in another country.

[17:20:38.0000] <gsnedders>
I like how the WHATWG people are always the "crew"

[17:20:48.0000] <gsnedders>
Is this some really common Americanism?

[17:40:17.0000] <tantek>
yes

[17:49:17.0000] <wanderview>
I think I heard the kids "squad" these days

[18:05:34.0000] <nox>
gsnedders: Used quite often in French hip hop too. :P

[18:06:06.0000] <MikeSmith>
gsnedders: looking at the invite-expert thing now

[18:09:50.0000] <MikeSmith>
gsnedders: done, afaict

[18:11:25.0000] <MikeSmith>
Apache project is so sad

[18:11:37.0000] <MikeSmith>
https://bz.apache.org/bugzilla/show_bug.cgi?id=47485#c20

[18:12:11.0000] <MikeSmith>
*Apache Web Server Project

[18:13:08.0000] <MikeSmith>
dunno why anybody in their right mind actualy willingly chooses apache unless they have no other others for some reason

[18:18:48.0000] <tantek>
MikeSmith because they have legacy .htaccess httpd.conf they don't want to try to figure out for new web server software?

[18:19:14.0000] <MikeSmith>
tantek: yeah probably so in a lot of cases

[18:19:20.0000] <MikeSmith>
but that too is a sad reason

[18:19:22.0000] <gsnedders>
MikeSmith: https://www.w3.org/2004/01/pp-impl/40318/join still says "[not authorized to join]"

[18:19:48.0000] <tantek>
MikeSmith - serving HTTP is not portable across implementations

[18:20:00.0000] <tantek>
definitely a weakness in the overall web platform

[18:20:16.0000] <MikeSmith>
yeah

[18:21:16.0000] <MikeSmith>
gsnedders: my thing says "Geoffrey Sneddon's Invited Expert status... Geoffrey Sneddon is an invited expert without Member access... This person is currently allowed to participate in:"

[18:21:22.0000] <MikeSmith>
it all looks right

[18:22:12.0000] <gsnedders>
MikeSmith: um…

[18:22:17.0000] <gsnedders>
MikeSmith: uh

[18:22:40.0000] <gsnedders>
MikeSmith: I've never been able to get this to work since I ceased being an Opera rep, FWIW

[18:22:46.0000] <gsnedders>
MikeSmith: so I guess there's some bad state somewhere

[18:22:57.0000] <MikeSmith>
gsnedders: maybe I can get it resend it

[18:23:02.0000] <MikeSmith>
lemme check on stuff

[18:26:08.0000] <MikeSmith>
gsnedders: try the one I just sent now

[18:26:15.0000] <MikeSmith>
your inbox

[18:26:34.0000] <gsnedders>
MikeSmith: that works

[18:26:45.0000] <MikeSmith>
rock n roll

[18:26:52.0000] <gsnedders>
MikeSmith: and so does the HTML one now too

[18:26:58.0000] <MikeSmith>
oh

[18:27:13.0000] <MikeSmith>
ok well you can join both

[18:27:53.0000] <gsnedders>
don't I need chairs permission for webapps?

[18:28:00.0000] <MikeSmith>
well

[18:28:12.0000] <MikeSmith>
officially I guess you're supposed to

[18:28:22.0000] <MikeSmith>
so Art may ask me about it

[18:28:44.0000] <MikeSmith>
but Art is my pal and we can work it out either way

[18:29:14.0000] <gsnedders>
also, how do I control what email gets auto-subscribed to the list? is it the default email on my account?

[18:29:17.0000] <MikeSmith>
but as far as the system is concerned, you're already in

[18:29:19.0000] <gsnedders>
/me forgets how this works

[18:29:24.0000] <MikeSmith>
yes

[18:29:42.0000] <MikeSmith>
the WG lists are so-called "DB-backed" lists

[18:29:54.0000] <MikeSmith>
if you're in the WG, you can't un-subscribe from them

[18:30:07.0000] <MikeSmith>
the only way to get off the mailing list is to leave the WG

[18:30:30.0000] <MikeSmith>
ah yeah

[18:30:33.0000] <gsnedders>
/me wonders if he should keep with the separate email account for mailing lists nonsense

[18:30:44.0000] <gsnedders>
it made more sense when I cared about space

[18:30:51.0000] <gsnedders>
like, gigabytes of emails mattering

[18:31:03.0000] <MikeSmith>
yeah, it's your acount e-mail address and you can"t change it to another address

[18:31:21.0000] <MikeSmith>
boo hoo hoo (about gigabytes of e-mail)

[18:31:37.0000] <gsnedders>
I'd love if it were possible for change it to another address on your account, FWIW

[18:32:17.0000] <MikeSmith>
it may actually be but if so I don't know how

[18:32:44.0000] <MikeSmith>
if you send a message to sysreq⊙wo you can see

[18:32:51.0000] <gsnedders>
/me decides to kill off foolistbar⊙gc now space is cheap and he hasn't actually sent any email from that account in years

[18:32:52.0000] <MikeSmith>
doesn't hurt to ask

[18:33:02.0000] <gsnedders>
so it doesn't matter at all :P

[18:35:51.0000] <MikeSmith>
wanderview: as far as "crew" vs "squad" the coolest word is actually "set"

[18:36:55.0000] <gsnedders>
MikeSmith: interestingly I only got an email for joining the webapps, not the html wg

[18:37:06.0000] <gsnedders>
was I somehow sorta a member still of the html wg? weird

[18:37:48.0000] <gsnedders>
/me wonders whether he's attending plenary day

[18:37:53.0000] <gsnedders>
without MikeSmith around it doesn't seem worth it

[18:56:13.0000] <MikeSmith>
plenary day is usually fun

[18:56:32.0000] <MikeSmith>
they do it unconference-style now

[18:57:05.0000] <MikeSmith>
after tantek helped get it set up that way 2-3 years back

[18:57:28.0000] <MikeSmith>
so it can be genuinely productive and enlightening

[18:57:34.0000] <MikeSmith>
breakout sessions

[20:15:48.0000] <cvrebert>
Anyone care to confirm that I'm reading the maxlength part of the HTML spec right?: http://jsbin.com/xutife/1/edit?html,js,output

[20:19:40.0000] <cvrebert>
Because if yes, then Firefox and Edge are buggy

[22:47:01.0000] <MikeSmith>
mkwst: https://w3c.github.io/webappsec/specs/powerfulfeatures/#example-ba3d2b06 makes me wonder if maybe you should introduce the notion/terminology of something having become "tainted"

[22:47:56.0000] <MikeSmith>
(the case of Shared Worker shared with an insecure context)

[22:48:11.0000] <MikeSmith>
also, the example might benefit from titles

[22:48:29.0000] <MikeSmith>
e.g., Example 10: Shared Worker shared with an insecure context

[22:49:07.0000] <MikeSmith>
e.g., Example 9: Shared Worker shared only with secure contexts

[22:50:44.0000] <mkwst>
MikeSmith: annevk suggested something similar in a GitHub issue. I'm not sure it's worth the complexity.

[22:52:01.0000] <mkwst>
https://github.com/w3c/webappsec/issues/406. Feedback on that bug would be helpful.

[22:55:15.0000] <MikeSmith>
/me looks

[22:56:44.0000] <MikeSmith>
fair enough

[22:57:02.0000] <MikeSmith>
Progress Not Perfection

[23:03:32.0000] <cvrebert>
In the hope that either a Mozilla or HTML forms spec wonk is around: https://bugzil.la/1203844

[23:07:28.0000] <annevk>
cvrebert: looks valid if it still applies in Nightly (haven't tested)

[23:07:47.0000] <annevk>
cvrebert: bugs in web standards you want to file against Core, not Firefox

[23:08:16.0000] <cvrebert>
annevk: tested in Dev Edition 42.0a2

[23:10:47.0000] <cvrebert>
annevk: I've had mixed experiences with pre-triaging like that; never gotten a response to some of them

[23:11:14.0000] <annevk>
cvrebert: hmm yeah I guess sometimes you need to copy folks

[23:11:34.0000] <annevk>
cvrebert: so maybe I just ruined it for you, huh?

[23:12:24.0000] <annevk>
Wow, MikeSmith is hacking Pascal

[23:16:29.0000] <MikeSmith>
I seriously like this code

[23:16:35.0000] <MikeSmith>
the Wattsi code

[23:16:59.0000] <MikeSmith>
the change I made is trivial but I took an opportunity to explore some of the rest of it

[23:17:07.0000] <MikeSmith>
and it's pretty clever

[23:17:13.0000] <MikeSmith>
e.g., the html parser

[23:20:00.0000] <cvrebert>
annevk: yeah. well, hopefully setting is as a dependency of the html5forms bug just spammed someone relevant

[23:20:27.0000] <MikeSmith>
cvrebert: Mozilla is rumored to have a secret IRC server called irc.mozilla.org or something like that, and secret #developers or some such channel where the developers would probably hang out if such a thing did exist

[23:20:34.0000] <MikeSmith>
just sayin'

[23:20:40.0000] <annevk>
Bug tracking for large projects gets so complicated

[23:23:01.0000] <MikeSmith>
cvrebert: there's also a magic phrase I saw someone use once that has special power to get implementor attention for a bug report

[23:23:12.0000] <MikeSmith>
"I have now invested quite a lot effort into this bug, time has come for you to act."

[23:26:15.0000] <cvrebert>
MikeSmith: Ah, the ol' "insult them so they help you just to spite you" gambit. http://www.2ality.com/2012/09/getting-help-linux.html

[23:32:04.0000] <mkwst>
MikeSmith: I usually hear "I'm going to move to Firefox unless you fix this!"

[23:32:16.0000] <mkwst>
Totally effective, by the way. I drop whatever I'm doing, every time.

[23:37:13.0000] <annevk>
I guess the holidays are over

[23:37:19.0000] <annevk>
Waking up to 41 unread threads is new

[23:51:46.0000] <annevk>
Whoa, code for merging big5 and big5-hkscs just landed https://bugzilla.mozilla.org/show_bug.cgi?id=912470

[23:51:52.0000] <annevk>
hsivonen++

[23:55:36.0000] <mkwst>
annevk: Any thoughts on https://github.com/w3c/webappsec/issues/263, many months later?

[00:01:31.0000] <mkwst>
Do you still think something like `navigator.permissions.query({ name: "secureContext" })` is a good model?

[00:02:24.0000] <annevk>
mkwst: no

[00:03:13.0000] <annevk>
mkwst: I think ideally we just make secure contexts part of HTML

[00:03:35.0000] <annevk>
mkwst: but it's still not clear to me if we can do for shared workers and several other things what would be ideal from a security perspective

[00:04:45.0000] <annevk>
mkwst: to make the Bs cross-origin in the setup insecure A -> secure B and secure C -> secure B

[00:05:34.0000] <mkwst>
annevk: Yeah. It's just not clear to me that that's enough of a risk to inject a good deal of complexity into the origin concept (and implementation, etc).

[00:06:03.0000] <annevk>
mkwst: but if we're not doing that, doing ancestor checks seems rather phony

[00:06:22.0000] <mkwst>
That said, I kinda want to do something like that. rbarnes pointed me to the Containers concept that's floating around Mozilla. It would be nice to allow sites to opt into something like that.

[00:07:20.0000] <annevk>
mkwst: which is rather straightforwardly done in HTML, if the environment was created based on a response whose HTTPS state is authenticated, ...

[00:07:23.0000] <mkwst>
annevk: Really? It covers a good chunk of the badness, doesn't it? The case that it doesn't cover is when a new window pops up and uses a shared worker to proxy data to a frame with an insecure ancestor, that then pumps the data to the insecure ancestor.

[00:07:46.0000] <MikeSmith>
annevk: (or anybody) do you know what the holdup is on SW client.navigate()?

[00:07:57.0000] <annevk>
MikeSmith: maybe JakeA knows

[00:08:09.0000] <MikeSmith>
k

[00:08:25.0000] <annevk>
mkwst: maybe, both bz and bholley weren't very convinced

[00:08:39.0000] <MikeSmith>
JakeA: https://code.google.com/p/chromium/issues/detail?id=500911 seems to be stalled since late June

[00:08:48.0000] <annevk>
mkwst: and when it comes to this, you want them on board

[00:09:14.0000] <annevk>
mkwst: I don't think rbarnes has wrestled with that code much, but I could be mistaken

[00:09:29.0000] <mkwst>
annevk: I think bz was more concerned about the sloppy ancestor chain walking than the concept. That was my read of https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0033.html.

[00:10:00.0000] <mkwst>
For clarity, the containers thing is a separate topic entirely. Related tangentially, but distinct from this conversation.

[00:11:17.0000] <annevk>
mkwst: I guess, maybe it just irks me that's it not properly grounded

[00:11:49.0000] <mkwst>
It's not clear what "properly grounded" means. :)

[00:12:09.0000] <annevk>
mkwst: once you start checking lists for bits you lose, basically, security-wise

[00:12:35.0000] <annevk>
mkwst: https://en.wikipedia.org/wiki/Ambient_authority

[00:13:03.0000] <annevk>
mkwst: at some point CORS had a thing where each redirect appended something to the Origin header and the server had to approve them all

[00:13:09.0000] <annevk>
mkwst: Mark Miller kinda destroyed that

[00:14:00.0000] <JakeA>
MikeSmith: ohhh, that was in Canary last I checked

[00:15:03.0000] <JakeA>
MikeSmith: ah, so it's blocked on security review. I'll chase it

[00:17:00.0000] <mkwst>
annevk: Pushing a taint bit down to each context is certainly doable.

[00:18:41.0000] <annevk>
mkwst: I think you misunderstood

[00:19:02.0000] <mkwst>
Enlighten me. :)

[00:19:06.0000] <annevk>
mkwst: I guess what I'm saying is that if this doesn't become a new type of origin, it's not grounded

[00:19:19.0000] <annevk>
mkwst: and just some additional checks to make things difficult

[00:21:28.0000] <mkwst>
We didn't change the origin concept for mixed content. Or certificate changes. Cookies continue to span across everything on an eTLD+1.

[00:21:47.0000] <mkwst>
I think that anything we do here will be "additional checks to make things difficult".

[00:22:18.0000] <mkwst>
For instance: if I can pop up a new window, I don't need the shared worker, as the frame and the window can communicate directly via `window.opener` or indirectly via `postMessage`.

[00:22:41.0000] <mkwst>
Splitting the origin prevents them from communicating via `localStorage` as well, but I'm not sure it does much more than that.

[00:27:48.0000] <annevk>
BroadcastChannel would stop working

[00:28:21.0000] <annevk>
Mixed Content was a mistake we're trying to fix, that's different

[00:28:34.0000] <annevk>
If we were to introduce HTTPS today, we wouldn't have Mixed Content

[00:28:51.0000] <annevk>
Same for eTLD+1

[00:30:52.0000] <mkwst>
(I've never heard of BroadcastChannel... guess I need to skim the spec?)

[00:31:43.0000] <annevk>
mkwst: it allows same-origin environments to communicate

[00:32:43.0000] <mkwst>
Interesting. Why do we need that?

[00:34:09.0000] <annevk>
mkwst: folks were abusing localStorage's storage events for it... it's an alternative to shared workers, which we were hoping folks would use

[00:34:32.0000] <MikeSmith>
heycam|away: if you care to comment https://github.com/whatwg/html/pull/137

[00:35:07.0000] <MikeSmith>
JakeA: thanks!

[00:36:02.0000] <mkwst>
Apparently https://crbug.com/161070

[00:36:48.0000] <mkwst>
Filed in 2012, worked on briefly in 2014, no one's on it right now.

[00:38:10.0000] <MikeSmith>
what's the +1 in eTLD+1 for?

[00:38:29.0000] <mkwst>
effective top level domain of `yay.appspot.com` is `appspot.com`.

[00:38:41.0000] <MikeSmith>
yeah that part I know

[00:38:48.0000] <MikeSmith>
oh

[00:38:51.0000] <mkwst>
eTLD+1 is `yay.appspot.com`, which is the first bit that you can set cookies on, etc.

[00:38:52.0000] <MikeSmith>
I see

[00:38:59.0000] <MikeSmith>
yeah

[00:39:02.0000] <mkwst>
+1 label.

[00:39:39.0000] <MikeSmith>
Yeah I could have figured that out if I had thought about it for a few seconds instead of asking

[00:39:45.0000] <MikeSmith>
thanks

[00:45:45.0000] <MikeSmith>
https://github.com/whatwg/html/blob/03aaf5e2f7e2af9663819556baa275ea38758295/images/asyncdefer.svg is another good diagram

[00:47:56.0000] <annevk>
I want a term for eTLD+1, I was thinking "site" but a URL's site just seems rather wrong

[00:48:22.0000] <annevk>
That's one of the things blocking a more formal definition of public suffixes in URL

[00:49:10.0000] <mkwst>
"registerable domain"?

[00:50:13.0000] <annevk>
mkwst: doesn't make sense for github.io

[00:50:30.0000] <annevk>
well maybe it does a bit for that one

[00:50:33.0000] <mkwst>
Sure it does. GitHub is the registrar, and hands out assignments based on usernames.

[00:52:43.0000] <annevk>
I guess it might be true for all of them, but in theory you could have a company that just wants defense-in-depth and applies for it therefore

[00:53:58.0000] <mkwst>
Sure. It's still the registrar.

[00:54:06.0000] <mkwst>
Just like Google is the registrar for `.google`.

[00:54:30.0000] <mkwst>
"registerable" doesn't mean "publicly registerable".

[02:25:42.0000] <annevk>
mkwst: I see a PR to the URL standard in your future :-P

[02:31:45.0000] <mkwst>
`git clone everything-that-anne-works-on`

[02:35:57.0000] <mkwst>
annevk: Where do you want it? "A URL's host is a registerable domain if blah blah labels blah blah publicsuffix.org blah." + "A URL is registerable if its host is a registerable domain."?

[02:37:14.0000] <annevk>
mkwst: perhaps it should be part of https://url.spec.whatwg.org/#hosts-%28domains-and-ip-addresses%29?

[02:37:34.0000] <mkwst>
Yeah. That's where I'm putting the first part. I guess we don't need the second part.

[02:38:10.0000] <annevk>
mkwst: note https://www.w3.org/Bugs/Public/show_bug.cgi?id=25865 in particular

[02:38:46.0000] <annevk>
mkwst: also, I haven't studied the cookie RFC and document.domain closely enough to know what hooks they would need to drop the direct dependency on publicsuffix

[02:38:55.0000] <annevk>
mkwst: we'd want to make sure this fix addresses that

[02:39:42.0000] <mkwst>
I'm poking at the Cookie RFC somewhat unwillingly already, so, yeah. `document.domain` just says something like "If value is a public suffix, reject."

[02:42:47.0000] <mkwst>
https://html.spec.whatwg.org/multipage/browsers.html#dom-document-domain step 4.3

[02:47:56.0000] <annevk>
mkwst: yeah, we could make that "if new value is not a registrable domain, throw"

[02:48:22.0000] <annevk>
mkwst: btw, it's registrable according to G, not registerable

[02:48:31.0000] <annevk>
registerrible

[02:49:38.0000] <mkwst>
Whatever. It's whatever we say it is. Referer, for instance.

[02:52:04.0000] <annevk>
I'll redefine you as Mike East, PR coming up

[03:01:34.0000] <mkwst>
If you find my spec, _please_ let me know. I'm so confused about so many things. :)

[03:26:02.0000] <jgraham>
mkwst: Have you read specs recently? "confused about many things" is their default state

[03:48:08.0000] <MikeSmith>
annevk: about https://github.com/whatwg/html-build/issues/26#issuecomment-139465986 what happened?

[03:57:10.0000] <annevk>
MikeSmith: so Domenic tried to pull in my PR and apply it, but due to my PR not being rebased it got lost since he didn't have history

[03:57:44.0000] <MikeSmith>
ah

[03:58:19.0000] <MikeSmith>
so that's fixable

[03:58:59.0000] <MikeSmith>
 when contributors get to the point that they have a branch ready to merge, we can tell them how to do it

[03:59:03.0000] <MikeSmith>
or we just do it

[03:59:35.0000] <annevk>
MikeSmith: well, Domenic tried to merge my thing but it got messed up since his local repo was not complete

[03:59:49.0000] <MikeSmith>
OK

[03:59:59.0000] <annevk>
MikeSmith: so I guess it's mainly a problem for any "team" folks if they use that setup

[04:00:02.0000] <MikeSmith>
yeah

[04:00:09.0000] <MikeSmith>
we need to document it in TEAM.md

[04:00:30.0000] <MikeSmith>
anyway I figured out a fix to a different problem that Domenic reported yesterday

[04:00:51.0000] <MikeSmith>
which is the the --depth 1 thing left him unable to get any other branches

[04:00:52.0000] <jgraham>
Having an incomplete local checkout just seems like it's asking for things to be more complicated than necessary

[04:02:09.0000] <MikeSmith>
jgraham: well the alternative is that first time every new contributor who doesn't already have a repo shows up, they have to sit for a long time waiting for the build to clone the entire history

[04:02:22.0000] <MikeSmith>
but I agree with you

[04:02:45.0000] <MikeSmith>
it's just, we will need to get the contributors to actually clone the whole history eventually

[04:03:05.0000] <MikeSmith>
just not the very first moment they try to get their environment set up

[04:05:06.0000] <jgraham>
Depends how long that actually takes I guess

[04:05:14.0000] <MikeSmith>
long

[04:05:20.0000] <MikeSmith>
too long

[04:06:34.0000] <MikeSmith>
it gets to around 24% and sorta hangs there every time

[04:07:10.0000] <MikeSmith>
why, I don't know, but it's 100% reproducbile

[04:07:39.0000] <MikeSmith>
and then it crawls along for a long time after that before it completes

[04:09:06.0000] <MikeSmith>
real 3m0.134s

[04:09:10.0000] <MikeSmith>
just tried it

[04:09:29.0000] <MikeSmith>
and that is over a ~100Mbs data connection

[04:09:35.0000] <jgraham>
MikeSmith: Pretty sure that Hixie added something big around commit 0.24 * 9000

[04:09:48.0000] <MikeSmith>
yeah I figured he must have

[04:09:52.0000] <MikeSmith>
oh I bet I know

[04:09:56.0000] <annevk>
We could just say it'll take a long time

[04:10:15.0000] <annevk>
I think that's better than ending up with half-working repos

[04:10:21.0000] <MikeSmith>
that's when he first added the class=impl stuff I bet

[04:10:45.0000] <jgraham>
So, based on the fact that I have worked with chromium, gecko and (shudder) B2G, 3 minutes for a clone is not a long time ;)

[04:11:23.0000] <MikeSmith>
annevk: I'm happy to do whatever we get agreement on, but I seriously think we should wait to worry about it until we have contributors show up and if we get actuall evidence that it's causing problems

[04:12:10.0000] <jgraham>
MikeSmith: My bias, which is worth very little here, is to tell people to do the most normal thing possible until people show up and start indicating that that causes a problem

[04:12:16.0000] <MikeSmith>
I would rather not preemptively try to avoid problems we don't have evidence we're gonna actually have

[04:13:01.0000] <MikeSmith>
jgraham: the problem I see with that plan is that they may give up and quit before they actually ever get started

[04:13:31.0000] <MikeSmith>
we put a lot of thought and time into trying to make the initial build as easy as possible for people

[04:13:53.0000] <jgraham>
If your commitment to the cause doesn't extend to waiting three minutes for a clone it doesn't seem like you are going to have a great time

[04:14:02.0000] <MikeSmith>
it would suck if we end up making it take 10 minuts or more for normal people to first try it

[04:14:25.0000] <jgraham>
I mean for a typo fix or whatever you don't need to make a clone at all, just use the GH UI

[04:14:40.0000] <mkwst>
jgraham: Does the GH UI work for a million line file?

[04:14:50.0000] <mkwst>
I suspect it falls down and dies.

[04:14:51.0000] <MikeSmith>
I wish sometime we would try a bit to think like normal people instead of self-selecting the way that works best for us

[04:15:08.0000] <mkwst>
MikeSmith: Normal people don't read the HTML spec.

[04:15:19.0000] <MikeSmith>
they do actually

[04:15:20.0000] <jgraham>
MikeSmith: My "thinking like normal people" mode tells me that normal people won't read the instructions

[04:15:29.0000] <MikeSmith>
for better or worse, they actually do

[04:15:38.0000] <jgraham>
they will try to do a clone in the way that they clone every other repo

[04:15:54.0000] <jgraham>
and then expect their normal repitiore of git knowledge to work

[04:16:03.0000] <MikeSmith>
that's the thing

[04:16:12.0000] <MikeSmith>
this is not from instructions

[04:16:22.0000] <MikeSmith>
the build does it automatically

[04:16:33.0000] <MikeSmith>
the git clone call

[04:17:16.0000] <jgraham>
mkwst: Seems it doesn't. That's annoying

[04:17:43.0000] <MikeSmith>
anyway, in the end I'm happy to make it do whatever we decide

[04:18:12.0000] <nox>
mkwst: You mean we aren't normal?

[04:18:14.0000] <MikeSmith>
but I would just like the decision to be based on some kind of evidence rather than on opinions

[04:18:22.0000] <nox>
13:15 <jgraham> MikeSmith: My "thinking like normal people" mode tells me that normal people won't read the instructions

[04:18:30.0000] <nox>
jgraham: I know how to save the Web, thanks to you.

[04:18:32.0000] <mkwst>
nox: _You_, of course, are normal. It's the rest of us.

[04:18:37.0000] <MikeSmith>
heh

[04:18:48.0000] <nox>
jgraham: When do we get Ikea in WHATWG?

[04:18:56.0000] <nox>
They should be the ones write the instructions!

[04:18:58.0000] <nox>
writing*

[04:19:11.0000] <MikeSmith>
"Please leave your sense of normalness at the door."

[04:19:45.0000] <jgraham>
We should replace specs with little pictoral diagrams of people trying to build a web browser

[04:20:12.0000] <jgraham>
"assembley will require dozens of people and about 10 years"

[04:20:20.0000] <MikeSmith>
:)

[04:20:51.0000] <nox>
jgraham: "578,567,543,154,102 pieces"

[04:46:58.0000] <annevk>
mkwst: only 120k lines or so

[04:48:02.0000] <mkwst>
annevk: close enough.

[04:48:20.0000] <annevk>
hah

[05:09:39.0000] <annevk>
So editing HTML makes TextWrangler a bit sluggish at times, anyone know if that can be improved?

[05:09:52.0000] <mkwst>
Use vim.

[05:09:55.0000] <gsnedders>
Use emacs.

[05:09:56.0000] <mkwst>
:P

[05:10:02.0000] <gsnedders>
Damnit, mkwst, you're too fast!

[05:10:10.0000] <mkwst>
Fewer characters.

[05:10:19.0000] <gsnedders>
Bah, real men use ed!

[05:10:25.0000] <annevk>
Hmm, if I turn off syntax highlighting for the document...

[05:13:25.0000] <mkwst>
Then your document will be black and white and boring.

[05:15:15.0000] <nox>
annevk: Long lines, maybe?

[05:15:29.0000] <nox>
If TextWrangler is as well-coded as Atom, I mean.

[05:23:25.0000] <nerocode>
Q&A peeps: why most web designers do their project in mac, not in pc?

[05:24:17.0000] <Ms2ger>
They don't

[05:25:20.0000] <jgraham>
Or at least [citation needed]

[06:16:32.0000] <annevk>
Oh wow, SVGSVGElement. They couldn't even copy the convention from HTMLHtmlElement

[06:30:42.0000] <gsnedders>
nerocode: conjecture: the Mac-only browsers are harder to test than the Windows-only browsers (there are free VMs for IE, there are no VMs for Safari)

[06:32:38.0000] <wanderview>
annevk: do you remember what we said in july about what to do with marking bodyUsed when the body is null vs empty?

[06:32:55.0000] <wanderview>
I'm having a hard time deciphering our final decision from https://etherpad.mozilla.org/streams-f2f-july

[06:33:28.0000] <annevk>
bodyUsed returns IsDisturbed(stream) || used flag

[06:33:29.0000] <annevk>
- used flag is only relevant when you transfer body to another request (via new Request(otherRequest)). (This can't be done for responses.)

[06:33:36.0000] <annevk>
wanderview: I think that's the relevant bit

[06:34:18.0000] <wanderview>
annevk: and we want to make bodyUsed true if you read an empty stream, but not true if the body is null?

[06:35:00.0000] <annevk>
wanderview: when body is null there's no stream to be disturbed

[06:35:08.0000] <wanderview>
right

[06:35:11.0000] <annevk>
wanderview: so yes, only empty stream

[06:52:15.0000] <wanderview>
thanks

[07:10:20.0000] <wanderview>
Domenic: annevk: what is wrong with requiring H2 if fetch is only going to be used with "the modern web">

[07:10:21.0000] <wanderview>
?

[07:40:55.0000] <annevk>
wanderview: it's weird

[07:41:10.0000] <wanderview>
annevk: whats weird now?

[07:41:11.0000] <annevk>
wanderview: and I don't understand the reasoning

[07:42:21.0000] <wanderview>
oh, my question... I already gave in on the gh issue

[07:42:41.0000] <annevk>
okay

[08:19:45.0000] <gsnedders>
bah, no zcorpan or any other current Opera person around

[08:19:59.0000] <gsnedders>
how am I meant to work out what this crazy test is doing?!

[08:23:42.0000] <jgraham>
hallvors: Aren't "Opera" and "crazy test" some sort of bat signal for you?

[08:24:49.0000] <gsnedders>
He doesn't have SVN access to work out the history of the test, which I think is what will make it easy to understand.

[08:25:24.0000] <jgraham>
He might have brain history that does the same thing

[08:25:35.0000] <gsnedders>
Though I did just install Opera 12 to try running tests there. Gee, the UI is even worse than I remember on OS X.

[08:51:12.0000] <annevk>
gsnedders: philipj is in the channel... not sure about around

[08:54:32.0000] <ytrezq>
Hello, I have someone claiming that the javascript: scheme is only to be used in the navbar and with <a> <frame> <iframe>. However I’ve unable to found reference to support this, or more exactly,all I found is an expired ɪᴇᴛꜰ draft that didn’t told anything about this.

[08:56:19.0000] <ytrezq>
May some please give a link to standard or recommendation please ?

[08:56:38.0000] <ytrezq>
May some please give a link to the relevant standard or recommendation please ?

[09:05:58.0000] <annevk>
ytrezq: https://whatwg.org/html

[09:06:39.0000] <annevk>
ytrezq: https://html.spec.whatwg.org/multipage/browsers.html#javascript-protocol is the specific reference

[09:07:07.0000] <annevk>
ytrezq: anywhere else javascript: is an unknown scheme and treated the same as a network error

[09:22:07.0000] <ytrezq>
annevk: thank you looks likes he was partly wrong by saying he saw it on w3c.org

[09:36:23.0000] <ytrezq>
annevk: but I still don’t see where this behaviour is written

[09:40:13.0000] <annevk>
ytrezq: W3C copies our work, so you can likely find it there too

[09:42:06.0000] <ytrezq>
abarth: no, I mean I still don’t see/understand where is the explained behaviour on https://html.spec.whatwg.org/multipage/browsers.html#javascript-protocol

[09:42:49.0000] <ytrezq>
(It’s true I also would like the ᴡ3ᴄ reference)

[09:43:30.0000] <ytrezq>
(probably need to be quoted here)

[09:45:22.0000] <ytrezq>
sorry abarth wanted to wrote annevk

[09:46:15.0000] <annevk>
ytrezq: well, that is the navigate algorithm, there's only a couple of elements that can cause that to be invoked, which automatically limits where you can use javascript successfully

[09:47:01.0000] <annevk>
ytrezq: anyway, I'd recommend to avoid javascript:, the only reason it's in the spec at all is because we cannot break the web

[09:48:01.0000] <ytrezq>
annevk: Yes I know.

[09:48:48.0000] <ytrezq>
the point was about allowing data: and javascript: scheme for the longdesc attribute

[09:49:07.0000] <ytrezq>
the longdesc attribute seems to behave like <a>

[09:49:34.0000] <ytrezq>
(if implemented via a click in the context menu)

[09:50:35.0000] <ytrezq>
%R Per that spec, it should only work in <a>, <frame>, and <iframe> (and notably not <object>; we just haven't gotten around to removing it there yet).%O

[09:51:05.0000] <ytrezq>
%R“ Per that spec, it should only work in <a>, <frame>, and <iframe> (and notably not <object>; we just haven't gotten around to removing it there yet).”%O

[09:52:19.0000] <annevk>
ytrezq: longdesc is obsolete, any implementation that supports it is wrong

[09:53:13.0000] <ytrezq>
even for html version4 ?

[09:53:37.0000] <annevk>
ytrezq: HTML doesn't have versions

[09:53:46.0000] <ytrezq>
ok html4 then

[09:53:53.0000] <annevk>
ytrezq: HTML4 is obsolete

[09:55:21.0000] <annevk>
Which reminds me, I should replace HTML5 with HTML in https://annevankesteren.nl/2007/04/html-red-pill I guess

[09:56:59.0000] <ytrezq>
thank you

[09:57:38.0000] <annevk>
/me strikes it to preserve history

[09:59:40.0000] <ytrezq>
And sorry for insisting, but how would the <embed> element violate the Origin Policy of the algorithm (can’t see how it is forbidden)

[10:00:11.0000] <annevk>
ytrezq: are you asking why <embed> wouldn't support javascript URLs?

[10:01:03.0000] <ytrezq>
ehmmm yes…

[10:01:11.0000] <ytrezq>
ehmmm yes I do…

[10:01:13.0000] <annevk>
ytrezq: well, <embed> doesn't use navigate

[10:01:45.0000] <annevk>
ytrezq: it fetches the resource itself, and fetching javascript URLs results in a network error

[10:02:16.0000] <annevk>
ytrezq: javascript URLs not working is not really related to the same-origin policy

[10:02:45.0000] <annevk>
ytrezq: <object> is similar to <embed> in that respect, btw

[10:04:17.0000] <ytrezq>
“doesn't use navigate” I still not understand what navigate is (or at least it’s concept).

[10:04:53.0000] <annevk>
ytrezq: it's an algorithm that describes how user agents navigate browsing contexts

[10:05:10.0000] <ytrezq>
ok

[10:05:23.0000] <annevk>
ytrezq: browsing contexts are what you see in e.g., a browser, and can be nested through <frame> and <iframe> and such

[10:06:07.0000] <annevk>
ytrezq: the link I gave you earlier points to a step in the navigate algorithm, it's quite long

[10:09:02.0000] <ytrezq>
So I guess only <iframe> <frame> and <a> use it ?(removing here other attributes are obsolete)

[10:11:16.0000] <annevk>
ytrezq: yeah, that seems about right, there's a bunch of other features that tie into navigate as well of course, but that's mostly script

[10:12:03.0000] <ytrezq>
I’m talking about ʜᴛᴍʟ ones

[10:12:43.0000] <annevk>
ytrezq: <area> too

[10:12:55.0000] <annevk>
ytrezq: and <form action> maybe

[10:13:37.0000] <annevk>
ytrezq: HTML is a tad ambiguous, since the standard defines many APIs too, but I suppose you just mean the markup bits

[10:14:31.0000] <ytrezq>
<input> ?

[10:15:11.0000] <annevk>
ytrezq: why would <input> use navigate?

[10:16:00.0000] <ytrezq>
it can take an src attribute

[10:17:00.0000] <annevk>
ytrezq: there's lots of elements that can fetch resources

[10:17:04.0000] <annevk>
ytrezq: has nothing to do with navigate

[10:18:12.0000] <annevk>
anyway, hopefully someone else can help you out further, taking a break

[10:25:13.0000] <ytrezq>
annevk: no not that much <applet> <base><head> <img> <ins> <audio> <audio> <button> <command> <html> <source> <video> <meta> <link>

[10:25:36.0000] <ytrezq>
annevk: no not that much <applet> <base><head> <img> <ins> <audio> <button> <command> <html> <source> <video> <meta> <link>

[10:27:59.0000] <jsbell>
Any mozillians about who have opinions on http://w3c.github.io/filesystem-api/ ?

[10:28:14.0000] <Ms2ger>
jsbell, did you ever submit those timing tests to wpt?

[10:29:38.0000] <jsbell>
Ms2ger: The microtasks vs. tasks ones? No... trying to find the gist or whatever I dumped them in now...

[10:30:24.0000] <jsbell>
Oh, yes, https://gist.github.com/inexorabletash/9bf9ff9c0c62c4bc814f - because gists are indexed by name of first file, not title. :P

[10:34:00.0000] <jsbell>
Ms2ger: Suggestion for a directory? (or you could do it, since you'll get all the <meta> tags right the first time etc)

[10:35:35.0000] <jgraham>
<meta> tags?

[10:35:42.0000] <jgraham>
Or are these reftests?

[10:35:43.0000] <jsbell>
or link or whatever

[10:35:55.0000] <jsbell>
see, this is why I shouldn't do it. :)

[10:36:15.0000] <jgraham>
My point is that unless they're reftests you shouldn't need to do much of anything

[10:36:33.0000] <jsbell>
heh. Well, suggest a directory. naming is hard

[10:36:50.0000] <jgraham>
I have no idea what these tests are :)

[10:36:55.0000] <jgraham>
Which spec?

[10:37:04.0000] <gsnedders>
/me wonders what the odds of dropping XPathEvaluator etc. are…

[10:37:59.0000] <jgraham>
jsbell: And re: filesystem api I guess you maybe want sicking?

[10:38:36.0000] <jsbell>
jgraham: I guess technically html - https://html.spec.whatwg.org/#processing-model-9

[10:38:53.0000] <jsbell>
jgraham: sorry, not multipage, don't click that. :P

[10:39:06.0000] <gsnedders>
somewhere in the html directory, then :P

[10:39:32.0000] <gsnedders>
I would find where exactly, but that'd mean reopening the spec which I just closed

[10:40:24.0000] <jsbell>
okay, sensible answers, I'm good

[10:42:13.0000] <jgraham>
jsbell: There's a system!

[10:42:34.0000] <jgraham>
directories are named after the id of the section headings

[10:42:42.0000] <jsbell>
yeah, yeah, got it now. :)

[10:43:57.0000] <jgraham>
html/webappapis/scripting/event-loops sounds about right

[10:44:15.0000] <jsbell>
yep, working on the patch now

[10:44:27.0000] <jgraham>
jsbell++

[10:46:09.0000] <Ms2ger>
jsbell++

[10:46:18.0000] <Ms2ger>
(Sorry, was afk baking cookies)

[10:46:18.0000] <jsbell>
ERR_OVERFLOW

[10:46:39.0000] <jsbell>
yummy, afk to find cookies

[10:56:49.0000] <Domenic>
gsnedders: not great, see stats quoted in https://github.com/whatwg/dom/issues/67

[10:57:25.0000] <gsnedders>
Domenic: k, that's what I thought

[11:05:06.0000] <nox>
XPath! So many memories.

[11:05:43.0000] <jsbell>
Ms2ger, jgraham: https://critic.hoppipolla.co.uk/r/5799

[11:09:22.0000] <jgraham>
jsbell: Awesome

[12:27:57.0000] <ccardona-work>
Good morning WHATWG crew! o/

[12:32:29.0000] <TabAtkins>
ccardona-work: Morning, Carlos. ^_^

[12:32:51.0000] <ccardona-work>
hey tab. Long time no chat. I hope all is well w/ you.

[16:48:47.0000] <Krinkle>
Could I have an account on the whatwg wiki?


2015-09-12
[17:17:38.0000] <MikeSmith>
Krinkle: I can make one for you

[17:19:51.0000] <Krinkle>
I'd like that :)

[17:20:58.0000] <MikeSmith>
should be on its way

[17:23:51.0000] <Krinkle>
Got it

[17:25:59.0000] <Krinkle>
Thanks

[17:31:27.0000] <MikeSmith>
cheers

[23:59:39.0000] <hallvors>
gsnedders: sorry, wasn't around much yesterday but I'm curious what crazy Opera test you were working on. Maybe it's even one of my old tests ;)

[23:59:52.0000] <hallvors>
did you figure it all out?

[01:22:14.0000] <jgraham>
hallvors: https://critic.hoppipolla.co.uk/r/5798

[01:33:17.0000] <hallvors>
Hm, I never wrote XPath tests and don't really know who did them. Tarquin?

[01:35:27.0000] <jgraham>
That was my second guess

[02:26:10.0000] <gsnedders>
Giorgi I would guess.

[02:27:25.0000] <gsnedders>
It's not Tarquin, though.

[02:36:18.0000] <gsnedders>
But yeah, the fun thing is they all contain a <green>This text should be green</green> but most of the time, no ancestor of that is selected by the XPath query, so I fail to see how the text was /ever/ made green. (nowadays the tests just say "PASSED" or "This text should be green", oddly)

[05:33:39.0000] <hallvors>
Giorgi - of course.

[11:34:15.0000] <mkwst>
MikeSmith/jgraham: Where's the right place to file a bug about w3c-test.org not serving gzipped files? :)

[11:42:20.0000] <MikeSmith>
mkwst: with me, if there's an existing config option that I need to set

[11:43:05.0000] <mkwst>
Idunno. All I know is that MANIFEST.json is 1.6mb, and takes a loooong time to download.

[11:43:27.0000] <mkwst>
http://w3c-test.org/MANIFEST.json <--- That one.

[11:43:52.0000] <MikeSmith>
well I think wptserve just doesn't handle gzipping

[11:44:01.0000] <mkwst>
Ah.

[11:44:37.0000] <MikeSmith>
well but if underlying pythin simpleHTTP thing does, then we can add something to wptserve

[11:46:19.0000] <MikeSmith>
http://stackoverflow.com/a/17064025/441757 suggests we may be able to add it without too much trouble

[11:46:32.0000] <MikeSmith>
certeainly it could be added regardless


2015-09-13
[18:23:03.0000] <JonathanNeal>
TabAtkins: is there a post somewhere with your latest theory on CSS nesting?

[18:24:31.0000] <JonathanNeal>
Most sources point to http://tabatkins.github.io/specs/css-nesting/ and I wasn’t sure if that was tracking with your latest idea.

[18:36:17.0000] <TabAtkins>
It's not, no.  I haven't updated the spec yet.

[18:37:14.0000] <JonathanNeal>
TabAtkins: ah, very good to know. Is your current thinking to use @ rules?

[18:37:58.0000] <TabAtkins>
Kinda.

[18:39:02.0000] <TabAtkins>
It's to allow naked embedding of style rules inside of other styles if the selector starts with &.  Otherwise, you can use the @nest <sel> {...} rule.

[18:40:02.0000] <JonathanNeal>
Where `&:hover` would be right, but `body &` would be wrong?

[18:40:13.0000] <TabAtkins>
Most nested selectors start with &, so that'd give you the no-overhead nesting of Sass most of the time.

[18:40:15.0000] <TabAtkins>
Yeah.

[18:40:52.0000] <JonathanNeal>
Were other hypothetically-valid characters considered besides ampersand?

[18:41:17.0000] <TabAtkins>
Multiple languages converged on &, so it's not even a question, really.

[18:42:26.0000] <JonathanNeal>
Okay. Developer brains, or at least mine, love to stick to something consistent. If @nest <sel> {} became a thing, I could quickly imagine best practices recommending @nest &:hover over &:hover.

[18:43:03.0000] <JonathanNeal>
Maybe that’s not useful to even say, but I’m musing on it. I definitely like the selector being alongside the at rule more than nested within it.

[18:44:41.0000] <JonathanNeal>
Would it be valid to use @nest in a way that could be done without it?

[18:45:50.0000] <TabAtkins>
Yeah, you can do whatever you want inside of @nest. The selector has to contain an &, that's all. It can be at the front if you want.

[18:46:04.0000] <JonathanNeal>
e.g. .foo { @nest &.bar {} @nest &.qux {} }

[18:46:09.0000] <TabAtkins>
Yeah.

[18:46:12.0000] <JonathanNeal>
Ah, so it has to contain an &, that was going to be my next question

[18:46:34.0000] <JonathanNeal>
I was going to see if .foo { @nest { color: red; } } was the same as .foo { color: red }

[18:46:38.0000] <TabAtkins>
Yeah, if we allow omitting that's just implying an "& " at the beginning, and I don't want to encourage that accidentally.

[18:46:53.0000] <TabAtkins>
There's no selector at all there!

[18:46:58.0000] <TabAtkins>
Gotta have *something*.

[18:47:28.0000] <TabAtkins>
But .foo { @nest & { color:red; } } is indeed the same as .foo { color: red; }

[18:47:55.0000] <JonathanNeal>
And .foo { @nest .bar {} } is also invalid because it must contain the &?

[18:48:07.0000] <TabAtkins>
Yeah.

[18:48:31.0000] <TabAtkins>
Encouraging descendant selectors by default isn't a friendly behavior, so I'd make you write it out on purpose.

[18:48:32.0000] <JonathanNeal>
Why do you prefer that over the implied & ?

[18:48:40.0000] <TabAtkins>
Gotta do @nest & .bar {...} if you want that.

[18:49:10.0000] <JonathanNeal>
Or, to what you just said, why do you think descendant selectors is an unfriendly default?

[18:51:40.0000] <JonathanNeal>
And multiple selectors will work like Sass as well? .a, .b { @nest &.c, .d & {} } === .a.c, .d .a, .b.c, .d .b {}

[18:52:18.0000] <TabAtkins>
Because descendant selector is slow, and defaulting people into that (so it takes *more* characters to do the faster &>.bar thing) is bad.

[18:52:28.0000] <TabAtkins>
Yeah (re multiple selectors)

[18:53:35.0000] <TabAtkins>
Semantics are that you can replace the & with a :matches() containing the outer selector.

[18:53:39.0000] <JonathanNeal>
Excellent. Thanks for sharing your brain on that. I think @nest <sel> is pretty readable to those of us who deal with change badly. :D

[18:54:35.0000] <JonathanNeal>
Ah, you are referring to .a, .b === :matches(.a, .b)?

[18:55:36.0000] <JonathanNeal>
:matches and @custom-selector are definitely my favorite experimental goodies.

[18:56:04.0000] <JonathanNeal>
With things like (40em < width <= 60em) being a close second.

[18:56:20.0000] <TabAtkins>
Yeah.

[18:56:56.0000] <JonathanNeal>
The doubledash gets a bit tiresome, but only on vars. If anyone is like me, you are going to catch yourself making this typo: --var(thing) WHOOPS

[18:57:59.0000] <JonathanNeal>
:--heading {}, no problem. @media (--mobile), no problem.

[18:58:08.0000] <JonathanNeal>
--var, every day

[18:59:57.0000] <TabAtkins>
Interesting.

[19:00:26.0000] <JonathanNeal>
I hope so, I didn’t want to waste your brain space with that, but I thought it was interesting too.

[19:00:44.0000] <TabAtkins>
I'm p sure I'll have a use-case for --foo keywords naked in properties in the future, which is why I didn't want to use them for variables.

[19:01:27.0000] <JonathanNeal>
Will keywords be like variables without inline fallbacks?

[19:01:36.0000] <JonathanNeal>
*custom keywords

[19:03:54.0000] <JonathanNeal>
@custom-media --mobile (width < 30em); @custom-selector: :--heading h1, h2, h3, h4, h5, h6; @custom-keyword: --blue #b3d4fc;

[19:04:16.0000] <JonathanNeal>
That could be a beautiful thing, if that’s what you are referring to.

[19:05:19.0000] <TabAtkins>
Dunno!

[19:05:37.0000] <JonathanNeal>
Haha. Tell me more about the future now!

[19:05:50.0000] <JonathanNeal>
Well, I really appreciate you sharing your thoughts on this.

[19:06:03.0000] <TabAtkins>
np

[19:08:34.0000] <JonathanNeal>
Is there anything like Sass mixin currently proposed?

[19:09:18.0000] <TabAtkins>
For simple mixins, I just proposed http://tabatkins.github.io/specs/css-apply-rule and the WG accepted it.

[19:09:43.0000] <TabAtkins>
(Per the minutes, it was a provisional acceptance pending me resolving some circularity issues, but I resolved those issues in off-record conversation.)

[19:15:47.0000] <TabAtkins>
JonathanNeal: Oooooh, and you just gave me a good idea.

[19:16:32.0000] <TabAtkins>
So, vars are generally the "theming" solution for custom elements.  You declare a few variables that your component uses, and people can set those to style them.  This avoids the need to have shadow-piercing selectors in CSS.

[19:17:01.0000] <TabAtkins>
But sometimes you want to offer the ability to *fully* style a particular element within the shadow. That's not practical to do with vars, as you'd need 400+ vars, one per property. That's crazy.

[19:17:35.0000] <TabAtkins>
So CSS mixins (the @apply rule) were a solution here - you could just pass in the styles you want as a mixin-var instead.

[19:17:50.0000] <TabAtkins>
But that doesn't let you respond to different *states* of the element, like if you want to apply :hover styles and the like.

[19:18:25.0000] <TabAtkins>
The component author could predefine a few mixin-vars for this purpose, but it requires them to think of all the combinations of pseudo-classes you might want ahead of time.

[19:19:35.0000] <TabAtkins>
We can fix this by mixing together mixins and nesting! You can do ".component { --theme: { color: blue; @nest &:hover { color: red; } }; }" and it'd work!

[19:19:42.0000] <TabAtkins>
Yay, I'm happy I found a solution there.

[19:38:06.0000] <JonathanNeal>
I’m absorbing what is happening there.

[19:39:50.0000] <JonathanNeal>
Oh, you’re using custom propert sets and @nest like Sass

[19:41:37.0000] <TabAtkins>
Similar to Sass mixins with nested rules, yes.  Just defined on the tree, like CSS vars are, rather than global like Sass.

[19:42:25.0000] <JonathanNeal>
I think I need to write my own rosette stone for @mixin to @apply to better fathom it.

[19:42:37.0000] <JonathanNeal>
*rosetta

[19:42:49.0000] <TabAtkins>
It's the same as the conversion from Sass vars to CSS vars.

[19:43:11.0000] <JonathanNeal>
I’m not sure how you pass in variables during an apply

[19:43:51.0000] <TabAtkins>
You don't (yet).

[19:43:59.0000] <TabAtkins>
I got plans for that in the future, but it's not in the v1 proposal.

[19:44:11.0000] <TabAtkins>
*Simple* mixins is the word of the day here.

[19:44:19.0000] <JonathanNeal>
Oh, I thought that’s the primary use case for mixins in Sass versus extend.

[19:45:28.0000] <TabAtkins>
It is! Without arguments, mixins is equivalent to placeholder extends in power.  But we have neither in CSS so far. ^_^

[19:45:45.0000] <JonathanNeal>
@mixin icon $type { background-image: url($type); } .thing { @include icon hamburger.svg; }

[19:45:53.0000] <TabAtkins>
(Equivalent in power, but the usage scenarios are slightly different, as they do the extension from different sides.)

[19:51:34.0000] <JonathanNeal>
Is --type passed in this scenario? https://gist.github.com/jonathantneal/f0cf9b1901ef32c6595d

[19:56:22.0000] <JonathanNeal>
I added some questions inside that gist next to the @apply usages.

[19:56:38.0000] <JonathanNeal>
Mostly, I’m trying to see how variable scope works.

[19:58:57.0000] <TabAtkins>
No. --icon is just a custom property that happens to have a specially-formatted value.  var() functions in a custom property are processed at the time the custom property is applied to an element.

[20:01:10.0000] <TabAtkins>
Later, there will be a way to define a var() that isn't substituted normally, just by @apply passing in some values.

[20:02:33.0000] <JonathanNeal>
For now, the first menu would get background-image: none because it got it from :root, the second menu would get background-image: url(hamburger.svg); because that was the matching var at the time it was applied, and the third menu is non-sense css?

[20:03:08.0000] <TabAtkins>
What menus? There's only one.

[20:03:25.0000] <TabAtkins>
OH, you added to the gist, let me check

[20:03:43.0000] <JonathanNeal>
You’re right. I just updated it to call them menu-1, menu-2, menu-3 to clear up the confusion.

[20:04:41.0000] <TabAtkins>
1 and 2 are both none; again, --icon is just a custom property with normal custom property semantics.  When you set --icon on the root element, it substitutes any var() functions based on the other custom properties set on the root.

[20:04:46.0000] <TabAtkins>
And yeah, 3 is just invalid.

[20:05:31.0000] <JonathanNeal>
Well, apply seems like a nicer version of @extend so far.

[20:05:49.0000] <TabAtkins>
The two do similar but different things, just like extend and mixin in Sass.

[20:06:08.0000] <JonathanNeal>
It it accepted vars somehow, it would be like a super breed of extend and mixin

[20:06:23.0000] <TabAtkins>
It's nothing like extend. ^_^

[20:06:51.0000] <JonathanNeal>
You’re right again. I meant placeholder extend.

[20:06:54.0000] <JonathanNeal>
Is that right?

[20:07:23.0000] <TabAtkins>
Only insofar as simple mixins and placeholder extends are similar in functionality.  They're not similar in semantics.

[20:08:13.0000] <TabAtkins>
(mixins requires the "target" element to opt into the styling.  extend puts the "targetting" responsibility on person writing the extend.)

[20:12:42.0000] <JonathanNeal>
Would variables be passed in like the .menu-3 example in v2?

[20:14:03.0000] <TabAtkins>
You'd need a different var() syntax in the custom property set, to indicate that it's a "late-bound var", but yeah, something like that.

[20:14:32.0000] <TabAtkins>
I have an example that I accidentally left in the spec with var(--theme-color late).

[20:14:50.0000] <TabAtkins>
Probably woudl use parens, not curlies.

[20:14:52.0000] <JonathanNeal>
Ha, I failed to notice that there wasn’t a comma.

[20:15:07.0000] <JonathanNeal>
I thought late was a css color I didn’t know about.

[20:16:13.0000] <TabAtkins>
I probably wanna make that more obvious, yeah.

[20:16:16.0000] <TabAtkins>
Maybe put it first

[20:16:22.0000] <TabAtkins>
var(late --theme-color) or something

[20:16:37.0000] <TabAtkins>
That probably works better with var(parent --foo) too.

[20:17:16.0000] <JonathanNeal>
parent being superior to late?

[20:17:21.0000] <JonathanNeal>
e.g. border: 1px solid var(parent --theme-color, none);

[21:05:52.0000] <TabAtkins>
JonathanNeal: Not superior. It just takes the variable value from the parent instead. Mainly useful for defining variables recursively, like --indent: calc(var(parent --indent) + 20px);

[23:53:49.0000] <annevk>
MikeSmith: thank you for working on https://github.com/whatwg/html-build/pull/28

[23:53:59.0000] <annevk>
MikeSmith: working on the big patch that is Fetch that will be a huge help

[23:54:11.0000] <annevk>
MikeSmith: finding typos is rather hard atm

[23:54:19.0000] <MikeSmith>
yeah

[23:54:30.0000] <MikeSmith>
I will try to land that later today

[23:55:06.0000] <MikeSmith>
I need to refine it so it works teh same both for local wattsi and remote wattsi

[01:04:00.0000] <annevk>
Man, Fetch integration is so much work

[01:04:09.0000] <annevk>
Not even close

[01:04:30.0000] <annevk>
I wonder how this is ever going to be reviewed...

[01:26:52.0000] <nox>
annevk: If I notice some tree building rules where tokens should be reprocessed in state A,

[01:27:06.0000] <nox>
and state A states that the same tokens should be reprocessed in state B,

[01:27:42.0000] <nox>
should that be patched to remove the superfluous indirection?

[01:30:05.0000] <annevk>
nox: maybe, if someone is willing to do the work and find a suitable reviewer (not sure if there's anyone besides hsivonen who could do that)

[01:30:19.0000] <annevk>
nox: I guess Hixie could review too, if he's willing

[01:30:25.0000] <nox>
I see.

[01:31:45.0000] <nox>
Mmh in fact it was the opposite.

[01:31:54.0000] <annevk>
nox: there's a lot to do, so refactoring is not really at the top of my list, although I guess you could say Fetch is refactoring...

[01:32:09.0000] <nox>
"in template" insertion mode says to reprocess "in head" for "base", "basefont", "bgsound", "link", "meta", "noframes", "script", "style", "template", "title",

[01:32:33.0000] <nox>
and to reprocess "in body" for any other start tag,

[01:32:59.0000] <nox>
and "in body" insertion mode says to reprocess "in head" too for the same start tags as in "in template".

[01:40:12.0000] <annevk>
Yeah, I think that's basically "in body" calling "in head"(token)

[01:40:40.0000] <annevk>
When I implemented that it wasn't very clear to me either though

[01:47:06.0000] <nox>
annevk: Yes yes, the clause is just repeated, it's a minor detail.

[01:47:16.0000] <nox>
annevk: I wonder if patches that "parameterises" the states would be acceptable.

[01:47:44.0000] <nox>
annevk: For example, I'm pretty sure that the original insertion mode is only related to the "in text" insertion mode.

[01:50:39.0000] <annevk>
nox: dunno, would have to see it

[02:58:31.0000] <MikeSmith>
so if a Safari user doesn't have their "Block pop-up windows" user preference set to off (the shipping default is off), Web pages that use document.open to create new windows just silently fail to that, and the only error that's logged to the console is "TypeError: undefined is not an object (evaluating 'foo.document')"

[03:01:27.0000] <MikeSmith>
that seems very unhelpful to developers who want to legitimate let users opt-in to some UX/UI that uses multiple windows, and are trying to troubleshoot problems reported by users; e.g., "ur page it doesn't work at all for my safari. nothing isn't show up"

[03:02:54.0000] <MikeSmith>
no "popup was blocked" indicator shows up in this case in the browser chrome

[03:05:19.0000] <MikeSmith>
actually I guess it's window.open

[03:35:20.0000] <hallvors>
gsnedders: When you mention it, I think I looked briefly at those tests at some point and was wondering about the same thing. I suppose there was a plan to add some JS scaffolding and the work was never finished, or just not committed to SVN?

[03:37:48.0000] <hallvors>
MikeSmith: in some (all?) browsers, document.open() will actually invoke window.open() if there is a string argument. Compat pressure because of content confusing window.open() and document.open(). You're not alone ;)

[04:49:40.0000] <MikeSmith>
hallvors: ah yeah I vaguely recall this now

[05:40:41.0000] <annevk>
hallvors: it must have been user agents that made the first error there, otherwise content couldn't confuse them

[05:44:39.0000] <hallvors>
annevk: ok, probably some browser vendor developer thinking "what if somebody got confused by the two open() methods.." although the odds that people sometimes ship untested JS into production is rather high

[08:15:09.0000] <jgraham>
mkwst: So I'm somewhat reluctant to add gzipping by default because it's an extra layer of complexity that doesn't correspond to the things that are being tested. But I agree we should have some way to enable it for specific files

[12:19:20.0000] <gsnedders>
hallvors: no idea. I never looked at them till recently. They were converted to reftests at some point, at least.

[14:23:06.0000] <hallvors>
jgraham mkwst: +1 for *not* gzipping by default. In the XHR test suite we have a file dedicated to returning gzipped content - https://github.com/w3c/web-platform-tests/blob/e5e8fb9ebc4d5b2220abff5679fa0781c01f2c05/XMLHttpRequest/resources/gzip.py

[14:23:26.0000] <hallvors>
I suppose it's trivial to enhance it to accept a ?file argument or something like that

[15:20:17.0000] <gsnedders>
is anyone using test infra such that gzip will effect loading time?


2015-09-14
[19:28:13.0000] <JonathanNeal>
Good evening!

[00:58:56.0000] <annevk>
Domenic: philipj: HTML in various places has algorithms that seemingly only take a single argument, when you read further you notice it has various <dfn>'d arguments and other constructs that are not explicit from the calling site

[00:59:23.0000] <annevk>
Domenic: philipj: I think generally we want to move away from those patterns right in favor of having a call site that doesn't hide the complexity of the algorithm?

[00:59:42.0000] <annevk>
Domenic: philipj: "navigate" in particular is extremely guilty of this

[00:59:43.0000] <philipj>
annevk: in general I would agree, do you have an example?

[00:59:52.0000] <philipj>
ok, I haven't ever read those algorithms I think

[01:00:00.0000] <annevk>
Domenic: philipj: I don't really plan on fixing this as part of the Fetch rewrite, mind you, but I just wanted to know whether we're on the same line

[01:01:06.0000] <Ms2ger>
Yeah, that would be nice

[01:01:13.0000] <annevk>
philipj: https://html.spec.whatwg.org/multipage/browsers.html#navigate only takes "a new resource", but then further down it asks if "exceptions enabled" is set, whether "explicit self-navigation override" is set, etc.

[01:01:30.0000] <Ms2ger>
But those should probably use named arguments, maybe using a <dl> in the caller

[01:01:38.0000] <philipj>
There are media element algorithms which talk about ending the algorithm which invoked the sub-algorithms, which is also a bit odd

[01:01:45.0000] <annevk>
philipj: and navigate of course also takes a target browsing context and a source browsing context

[01:02:04.0000] <annevk>
Ms2ger: yeah, maybe, not sure yet

[01:02:25.0000] <annevk>
Ms2ger: perhaps a "record"

[01:02:56.0000] <annevk>
Ms2ger: ideally IDL was maintained and those maintaining figured out the conventions for everyone to use

[01:03:35.0000] <Ms2ger>
There's also some algorithm that says "If this was called by the click() method..."

[01:04:29.0000] <annevk>
Yeah, I'd generally favor making all that explicit myself, without having algorithms grab global or English-language state

[01:06:27.0000] <philipj>
annevk: fully agreed in principle, but in some specific cases trying to fix it might reveal something interesting, who knows

[01:10:28.0000] <Ms2ger>
philipj, even better :)

[01:28:23.0000] <jgraham>
gsnedders: *affect

[01:31:07.0000] <Ms2ger>
Good morning to you too

[01:45:41.0000] <JakeA>
annevk: I assume fetch doesn't support file:// urls, but can't find the failure point in the spec

[01:46:02.0000] <JakeA>
oh wait yes I can

[01:46:04.0000] <JakeA>
sorrrrrry

[01:52:18.0000] <annevk>
JakeA: it kinda does and doesn't

[02:45:59.0000] <annevk>
philipj: MikeSmith suggested not committing anything without PR anymore

[02:46:26.0000] <annevk>
philipj: oh never mind, I missed something

[02:47:53.0000] <philipj>
annevk: there was a PR for the most recent thing, but not "Add missing newline to link-fixup.js" last week if that's what you mean

[02:48:06.0000] <annevk>
philipj: I meant the most recent thing

[02:48:30.0000] <annevk>
philipj: and I forgot to look first

[02:48:33.0000] <philipj>
then I plead not guilty :)

[02:48:41.0000] <philipj>
no problem

[02:49:41.0000] <annevk>
/me goes back to Fetch

[05:17:15.0000] <annevk>
Oh my, "A Somewhat Critical View of SOP"

[05:17:28.0000] <annevk>
Perhaps public-webappsec is no longer useful either given the existence of GitHub...

[05:51:26.0000] <zcorpan_>
/me looks at https://whatwg.org/issues/

[05:54:03.0000] <annevk>
zcorpan_: Hixie was going to look into a way to share that data directly with the other editors somehow

[06:01:56.0000] <Ms2ger>
That data?

[06:02:09.0000] <Ms2ger>
Oh, that

[06:02:16.0000] <Ms2ger>
/me misread the url

[06:02:18.0000] <ato>
When an element is contenteditable or a document is in designMode, is there a way to get its original, default value?

[06:03:43.0000] <annevk>
ato: it?

[06:04:31.0000] <annevk>
ato: oh, https://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html hasn't really worked out thus far

[06:04:49.0000] <annevk>
ato: you'd have to keep track yourself using mutation observers

[06:05:06.0000] <mkwst>
annevk: I'm trying to move interesting conversations to GitHub. The mailing list is getting too large to get work done.

[06:05:12.0000] <mkwst>
re:webappsec

[06:05:14.0000] <ato>
annevk: Say I have a <p contenteditable> and change its textContent.  Is there an attribute, like <input>’s default value, that lets me get p’s text content before it was changed?

[06:05:46.0000] <ato>
annevk: I was looking at https://w3c.github.io/editing/contentEditable.html and https://w3c.github.io/editing/contentEditableEvents.html which HTML references.

[06:06:02.0000] <annevk>
ato: there's no such thing

[06:07:17.0000] <ato>
Okay.  I imagine because changing an editable element that isn’t plaintext-only and storing its original subtree would be quite difficult.

[06:38:24.0000] <zcorpan_>
gsnedders: r'ed https://critic.hoppipolla.co.uk/r/5798

[06:40:15.0000] <zcorpan_>
ato: there was something called UndoManager or some such, but i don't know if that caught on or what it let you do exactly

[06:40:51.0000] <Ms2ger>
I think only Gecko implemented it

[06:40:56.0000] <Ms2ger>
Not sure if it's still around

[06:43:03.0000] <zcorpan_>
https://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html

[06:44:01.0000] <annevk>
/me mentioned that earlier

[06:48:55.0000] <zcorpan_>
Ms2ger: heh, didn't notice https://critic.hoppipolla.co.uk/r/5775 was already merged

[06:50:06.0000] <Ms2ger>
zcorpan_, that tends to happen when the branch is called something like sync_840fcde37e45439b28d28c0bf57b58ab8ab85162 :)

[07:02:31.0000] <zcorpan_>
annevk: Domenic: r? https://critic.hoppipolla.co.uk/d789a554?review=5799 (i see your names in the blog post, so)

[07:04:41.0000] <annevk>
zcorpan_: blog post?

[07:04:54.0000] <zcorpan_>
https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

[07:05:52.0000] <ato>
annevk, zcorpan_: Thanks both (-:

[07:09:26.0000] <annevk>
zcorpan_: r+

[07:10:28.0000] <zcorpan_>
thx

[07:12:01.0000] <zcorpan_>
do you guys still have interns? i recall automating tests with WebDriver is something some opera interns did a few years ago

[07:13:18.0000] <Ms2ger>
Would be nice to do once we have webdriver infra

[07:15:34.0000] <jgraham>
Well it would be nice to get an intern to write the webdriver infrastructure. Or at least start it

[07:15:57.0000] <jgraham>
Guess I could have proposed that as an Outreachy project or something.

[07:16:19.0000] <Ms2ger>
We should track those intern ideas somewhere

[07:16:53.0000] <Ms2ger>
Issues in the wpt repo?

[07:17:06.0000] <jgraham>
Sure, why not

[07:18:03.0000] <jgraham>
Ms2ger: Create a label like size:project or something?

[07:18:45.0000] <jgraham>
(seems not quite orthogonal to difficulty, mind you)

[07:25:23.0000] <zcorpan_>
/me wonders if http://w3c-test.org/html/semantics/forms/constraints/form-validation-validity-tooLong.html is wrong

[07:26:52.0000] <zcorpan_>
seems so

[07:27:22.0000] <zcorpan_>
https://github.com/w3c/web-platform-tests/issues/2152

[07:41:08.0000] <zcorpan_>
jgraham: hmm, i can't merge in w3c/testharness.js

[07:42:14.0000] <zcorpan_>
https://github.com/w3c/testharness.js/pull/147 is reviewed, not merged

[07:43:49.0000] <Ms2ger>
Try again

[07:44:01.0000] <jgraham>
Well it would be nice to squash the PR too

[07:44:40.0000] <Ms2ger>
TIL about https://github.com/w3c/rdf-tests

[07:49:52.0000] <zcorpan_>
https://github.com/w3c/web-platform-tests/pull/2159 has no critic link

[07:50:14.0000] <zcorpan_>
Ms2ger: thanks

[07:51:12.0000] <Ms2ger>
Np

[07:55:14.0000] <zcorpan_>
MikeSmith: r? https://critic.hoppipolla.co.uk/r/5796

[07:55:38.0000] <zcorpan_>
MikeSmith: seems v.nu doesn't think it's valid

[07:56:40.0000] <zcorpan_>
/me was confused until he noticed "conformance-checker" in the path

[08:09:21.0000] <gsnedders>
zcorpan_: takk

[08:25:51.0000] <schalkneethling>
annevk: hi!

[08:29:06.0000] <schalkneethling>
apologies for hampering on about the video element and crossorigin ;) but, I just wanted to double check with you. You mentioned the other day that if you are loading content from an external resource using the video element, you always have to use the crossorigin attribute. Also, there is no connection between it and the CSP so, does this mean that even if the resource sends CORS headers back, you still need the crossorigin attrib

[08:33:53.0000] <schalkneethling>
annevk: ^^

[08:41:56.0000] <zcorpan_>
schalkneethling: missing " *and* you want to access the video data e.g. in a <canvas>" -- if you just want it to play, you don't need crossorigin=""

[08:45:03.0000] <zcorpan_>
schalkneethling: if you omit the crossorigin attribute, the browser does a regular request and ignores any CORS headers in the response. if you use the attribute, the response must have the right CORS headers or the browser will reject the response

[08:46:29.0000] <zcorpan_>
schalkneethling: without crossorigin="", if the response is not same-origin, you can paint it on a canvas but it will taint the canvas such that read operations will start throwing

[08:55:01.0000] <schalkneethling>
zcorpan_: thanks a ton for the information

[09:01:40.0000] <zcorpan_>
np

[09:03:13.0000] <zcorpan_>
schalkneethling: <video><track src> does however need the crossorigin attribute (on the video element) to load cross-origin tracks at all

[09:03:41.0000] <schalkneethling>
ah, thanks. Will make a note of that

[09:21:13.0000] <MikeSmith>
botie, inform zcorpan_ about https://critic.hoppipolla.co.uk/r/5796 (SVG thing) yeah I've spoken with the commenter and I need to also fix the bug in the checker code

[09:21:14.0000] <botie>
will do

[09:21:20.0000] <MikeSmith>
botie, inform zcorpan about https://critic.hoppipolla.co.uk/r/5796 (SVG thing) yeah I've spoken with the commenter and I need to also fix the bug in the checker code

[09:21:20.0000] <botie>
will do

[09:27:03.0000] <ccardona-work>
Good morning/afternoon/evening all

[09:27:54.0000] <MikeSmith>
oorale ccardona-work

[09:28:42.0000] <JakeA>
Domenic: do you have that progress events example to hand? The streams one

[09:28:54.0000] <Domenic>
JakeA: https://gist.github.com/domenic/95e689d0be5e24fb08ec

[09:29:01.0000] <JakeA>
Cheers!

[09:29:11.0000] <ccardona-work>
✌🏽MikeSmith

[09:29:51.0000] <ccardona-work>
o/ MikeSmith

[10:14:21.0000] <botie>
zcorpan, at 2015-09-14 16:21 UTC, MikeSmith said: about https://critic.hoppipolla.co.uk/r/5796 (SVG thing) yeah I've spoken with the commenter and I need to also fix the bug in the checker code

[10:33:18.0000] <Domenic>
hober: sent you an invite to the html team on GitHub so we can assign issues to you.

[11:25:23.0000] <MikeSmith>
hober: thanks for the remove-wget change

[11:25:47.0000] <MikeSmith>
Domenic & hober I'm working on the build script further and will have something to test later today

[11:26:20.0000] <MikeSmith>
for the line-numbers issue plus other things that came up during review

[11:26:30.0000] <Domenic>
\o/

[11:37:26.0000] <TabAtkins>
annevk: I *strongly* agree with the "put all the arguments up front so it's clear how to invoke the algorithm" position.

[11:51:42.0000] <Krinkle>
Ugh, so apparently in Safari, doing !window.performance -> window.performance = [], !performance.mark -> performance.mark = function () {}; Doesn't work. About 4/10 page loads it remains undefined.

[11:51:54.0000] <Krinkle>
{} *, not []

[11:52:05.0000] <Krinkle>
Even on my local machine, it's undefined one page load, defined the next.

[11:52:25.0000] <Krinkle>
Making no sense whatsoever. https://phabricator.wikimedia.org/T112287#1638614

[13:34:10.0000] <JonathanNeal>
TabAtkins: I expect to have the PostCSS transpiler for CSS nesting complete tonight. I’ll give it a playground so I can generate examples and maybe then you can tell me if I got anything wrong. :)

[13:34:50.0000] <JonathanNeal>
(not sure if transpiler is the right word, polyfill feels wrong)

[13:36:13.0000] <TabAtkins>
JonathanNeal: Cool.

[13:36:30.0000] <TabAtkins>
PostCSS is a preprocessor.  Which is another word for "compiler", yeah.

[13:37:12.0000] <TabAtkins>
And "transpile" is a neologism for when we recognize the output language as a language in its own right, rather than just a machine language that humans aren't expected to look at.

[13:37:20.0000] <JonathanNeal>
Does that make babel a preprocessor?

[13:41:45.0000] <JonathanNeal>
I think I get it. Thanks for helping me understand the definitions.

[13:42:46.0000] <JonathanNeal>
/me goes back to writing the plugin for a preprocessor that transpiles CSS by a yet updated draft of a CSS module.

[13:42:57.0000] <JonathanNeal>
Well, I’ll write it later, at least.


2015-09-15
[23:29:20.0000] <annevk>
Kinda wish we had removed that wget dependency before I installed it

[23:29:40.0000] <annevk>
Oh well, now the next person won't have to

[00:10:07.0000] <MikeSmith>
yeah

[00:14:33.0000] <cvrebert>
Is it just me, or is drafts.csswg.org unreachable?

[05:32:46.0000] <Ms2ger>
Nice: http://www.computerworld.com/article/2851719/slack-now-lets-employers-tap-workers-private-chats.html

[05:55:00.0000] <ato>
Ms2ger: Isn’t that what we’re switching to? (-:

[06:01:14.0000] <jgraham>
Well to be fair to them, it sounds like it's non-trivial to enable and clear when it is enabled

[06:01:25.0000] <jgraham>
And I hope no one is switching to them!

[06:05:47.0000] <gsnedders>
MikeSmith: why have I left the HTML WG?

[06:07:54.0000] <Ms2ger>
Because it's a cesspit of flamewars and inscrutable Process?

[06:10:41.0000] <MikeSmith>
gsnedders: you only were joined for like one day

[06:11:02.0000] <MikeSmith>
I have no idea why it kicked you

[06:11:21.0000] <MikeSmith>
maybe your affiliation changed?

[06:11:30.0000] <gsnedders>
nothing indicating that?

[06:11:38.0000] <gsnedders>
And /I/ haven't changed anything!

[06:11:41.0000] <MikeSmith>
nothing I can see

[06:11:52.0000] <MikeSmith>
well anyway you're not missing anything

[06:12:14.0000] <MikeSmith>
I don't know why you don't just join webapps wg isntead

[06:12:23.0000] <gsnedders>
I have joined webapps :P

[06:12:28.0000] <MikeSmith>
ah ok

[06:13:55.0000] <wilhelm_>
I'd kick out gsnedders too.

[06:32:23.0000] <jgraham>
/me concludes that wilhelm_ is the ghost in the machine

[06:40:23.0000] <wilhelm_>
/me changes his business card.

[06:49:19.0000] <annevk>
Hmm

[06:49:25.0000] <annevk>
GitHub can't show the diff for my Fetch PR

[06:53:24.0000] <Domenic>
This should be fun

[06:53:35.0000] <Domenic>
It'll be best to review the HTML diff anyway

[06:54:31.0000] <Domenic>
In the end though this is going to be one of those PRs where you mostly just trust the author. Maybe we'll spot some editorial things.

[06:58:29.0000] <tantek>
annevk: just ship it and have people review the total end result.

[06:58:57.0000] <jgraham>
annevk: Pointer?

[07:00:20.0000] <annevk>
https://github.com/whatwg/html/pull/144

[07:00:54.0000] <annevk>
tantek: idea is currently that changes to the HTML Standard will get some review first

[07:03:22.0000] <jgraham>
That's not even a very big diff

[07:03:28.0000] <jgraham>
All these tools suck :(

[07:04:03.0000] <tantek>
annevk - ok

[07:04:53.0000] <Ms2ger>
There's always https://github.com/whatwg/html/pull/144.diff

[07:09:04.0000] <zcorpan>
wtf github

[07:09:56.0000] <zcorpan>
should we use critic?

[07:10:30.0000] <zcorpan>
i suppose critic is differently annoying in that it gets confused if you --amend

[07:11:04.0000] <Ms2ger>
Maybe reviewable

[07:11:17.0000] <jgraham>
reviewable refuses to display the spec

[07:11:20.0000] <Ms2ger>
But both suck at reviewing single-file diffs

[07:11:39.0000] <annevk>
Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21674 so many fun cross-origin scripting issues

[07:11:43.0000] <jgraham>
I'm happy to try critic, but the no-force-push thing does seem to upset people

[07:11:59.0000] <jgraham>
I mean I'm happy for you to try critic

[07:12:57.0000] <annevk>
We do use force push

[07:14:44.0000] <jgraham>
But you don't have to, is the point

[07:15:33.0000] <jgraham>
Right up until you want to rebase and have merge conflicts and want them reviewed, or until the review is accepted if you don't have push access yourself

[07:15:57.0000] <annevk>
True

[07:17:28.0000] <zcorpan>
/me views the diff in GitUp

[07:19:44.0000] <zcorpan>
annevk: data-noexport="" vs. data-noexport - any reason not to use the latter?

[07:20:05.0000] <annevk>
zcorpan: style consistency

[07:20:33.0000] <annevk>
zcorpan: I would be okay with a PR to change the style throughout though, and drop ="" everywhere

[07:20:40.0000] <zcorpan>
k

[07:20:47.0000] <annevk>
zcorpan: provided wattsi can handle that

[07:21:20.0000] <zcorpan>
i'm sure Hixie implemented that part of the tokenizer correctly :-)

[08:01:31.0000] <annevk>
(Thanks for the feedback on the Fetch PR, will address it tomorrow. Have been working on that for over a week so taking a small break.)

[08:23:33.0000] <JakeA>
TabAtkins: If a flexbox contains wrapped items, is there a way to make the parent box the width as the longest line?

[08:23:48.0000] <JakeA>
Rather than width of the flexbox's container

[08:24:35.0000] <TabAtkins>
width:max-content, though support is spotty currently

[08:24:50.0000] <TabAtkins>
Oh wait

[08:24:59.0000] <TabAtkins>
Never mind, I see what your asking for

[08:28:51.0000] <TabAtkins>
I don't *think* there is. Shrink-wrapping doesn't work; once a float has to wrap, it's full-size regardless.

[08:56:55.0000] <annevk>
Domenic: whoa that Twitter discussion

[08:57:05.0000] <Domenic>
yeah, meh

[08:57:29.0000] <annevk>
Domenic: splitting a response across a Response class and some Error subclass seems mighty weird

[08:57:45.0000] <Domenic>
I think the current design is great.

[08:58:49.0000] <JakeA>
ohh, that discussion took to Twitter did it?

[08:59:33.0000] <JakeA>
TabAtkins: is https://drafts.csswg.org/css-sizing-3/#fit-content-size it?

[09:00:19.0000] <TabAtkins>
No, that's shrink-wrapping

[09:05:06.0000] <annevk>
JakeA: https://twitter.com/trodrigues/status/643705867767054336

[09:10:13.0000] <JakeA>
hm, I replied in the comment

[09:10:14.0000] <JakeA>
s

[09:12:21.0000] <annevk>
ah good

[09:24:40.0000] <JakeA>
fwiw, I'd still like an option to reject on !response.ok

[09:25:04.0000] <JakeA>
But maybe only cache.addAll benefits from that, in which case that option should go there

[09:27:39.0000] <nox>
TabAtkins: With the new CSS specs you are writing, is there anything that allow us to express https://html.spec.whatwg.org/multipage/#magic-border-selector?

[09:29:05.0000] <TabAtkins>
No; we don't yet have anything in Selectors that parses attribute values as anything other than strings.

[09:30:22.0000] <TabAtkins>
We have a pending suggestion, currently punted to level 5, to allow numeric comparisons in the attr selector, so you could write ":matches([border < 0], [border > 0])", or if you only care about positive values, just [border > 0].

[09:31:22.0000] <zcorpan>
TabAtkins: i suppose that wouldn't use html's "rules for parsing non-negative integers"

[09:31:26.0000] <nox>
TabAtkins: Nice.

[09:31:37.0000] <TabAtkins>
zcorpan: Nah, would use CSS's rules for parsing integers.

[09:31:44.0000] <TabAtkins>
Which is probably okay to switch to, compat-wise?

[09:31:51.0000] <nox>
They are different? :o

[09:31:59.0000] <TabAtkins>
Dunno, probably a little.

[09:32:59.0000] <TabAtkins>
Looking over it, CSS's rules are more expansive.

[09:33:14.0000] <zcorpan>
TabAtkins: got a link to css's rules?

[09:33:40.0000] <TabAtkins>
The numeric comparer would almost certainly just parse the attr as a <number>, not an <integer>, and CSS allows scinot.

[09:33:45.0000] <TabAtkins>
I think it's a strict superset.

[09:34:07.0000] <TabAtkins>
zcorpan: https://drafts.csswg.org/css-syntax/#consume-a-number

[09:34:39.0000] <TabAtkins>
zcorpan: Assuming we strip whitespace, which we would.

[09:37:46.0000] <Domenic>
JakeA: and I still think you actually want something more composable than that for cache.addAll, like a general way of guaranteeing atomicity or doing rollbacks or similar, on any condition not just the single built-in one.

[09:38:02.0000] <zcorpan>
TabAtkins: i suppose it would be a bit weird to use css's number parsing here in an html attribute but html's rules elsewhere. but also, it's super-annoying to have different rules in JS/HTML/CSS

[09:55:48.0000] <nox>
:integer(border) < 0? :P

[09:57:02.0000] <JakeA>
TabAtkins: btw, the layout we were looking at was http://jsbin.com/qufiza/edit?html,css,output, where the block of items were centered, but the items were still left aligned

[09:57:22.0000] <nox>
TabAtkins: Couldn't just the numeric comparer keep the type flag as integer in attribute selector context?

[09:58:42.0000] <nox>
Oh wait, some HTML attributes correspond to presentational hints that must be parsed as numbers, I guess?

[09:59:33.0000] <zcorpan>
nox: you wouldn't want integer for all attributes. e.g. <input step=0.5>, <div data-foobar=...>

[09:59:46.0000] <nox>
zcorpan: I see.

[10:01:42.0000] <TabAtkins>
CSS actually matches JS really closely now. Would have to look up the spec to see how exactly, but since we added scinot it got a lot closer.

[10:02:51.0000] <TabAtkins>
And CSS *integers* match HTML exactly, it's just that there's no real call for an "integer only" falling in the numeric comparison selectors.

[10:03:12.0000] <TabAtkins>
s/falling/flag/

[10:05:01.0000] <zcorpan>
TabAtkins: html ignores trailing garbage, which in css makes it a dimension instead of an integer, no?

[10:05:19.0000] <zcorpan>
border="1em"

[10:05:29.0000] <TabAtkins>
There's nothing wrong with a rule like [border >0] { border-width: attr(border px); } except for minor compat

[10:05:46.0000] <TabAtkins>
Oh, didnt know it ignored garbage.

[10:05:55.0000] <TabAtkins>
It would just be invalid in CSS then

[10:06:22.0000] <TabAtkins>
Since yeah, that would parse as a dimension rather than a number.

[10:06:54.0000] <TabAtkins>
(That rule was very annoying to type in a phone keyboard.)

[10:07:56.0000] <TabAtkins>
So assuming that's necessary, CSS won't really be able to help.

[10:08:47.0000] <zcorpan>
i don't know what the compat situation is, but i suppose there's non-zero amount of trailing "px" in html, and it would be bad to break that. maybe we could start supporting number-or-dimension, but personally i'm not so interested in pursuing that

[10:09:57.0000] <TabAtkins>
Yeah. CSS isn't interested in supporting that with syntax either, so not much worth in changing HTML.

[10:28:28.0000] <yhirano_>
wanderview, Domenic, annevk:  are you guys going to attend TPAC 2015? I may be there and it would be great if we can talk about streams / fetch.

[10:29:24.0000] <wanderview>
yhirano_: annevk and I will be there... I think Domenic said he would not be there

[10:31:40.0000] <wanderview>
yhirano_: would be great to meet and talk about streams/fetch

[10:31:50.0000] <Domenic>
yhirano_: I will be in Japan around that time for vacation but not for TPAC. I could meet up in Tokyo before/after if desired.

[10:34:48.0000] <yhirano_>
wanderview: thanks,  let's talk. maybe in an adhoc meetings slot? (I've never attended TPAC, so please correct me if I'm wrong)

[10:36:55.0000] <wanderview>
yhirano_: I've never been there either... I'm sure we can find time, though... I'll be there Mon to Thu morning

[10:39:06.0000] <yhirano_>
Domenic: yeah, if you could. Maybe we have blink-specific things (e.g. v8 extras) to talk about, too. I'm sorry I couldn't spend enough time for it this quarter.

[10:42:27.0000] <yhirano_>
Domenic: but I will be in MTV /SFO in Nov (for BlinkOn), so feel free to enjoy your vacation.

[10:50:41.0000] <yhirano_>
wanderview: thank you.

[10:56:01.0000] <Domenic>
yhirano_: sounds good! I will also be at BlinkOn. We can figure out a specific plan as the time draws closer.

[10:58:27.0000] <schalkneethling>
still trying to make sense of the crossorigin attribute on the video element :-/ Who would have thought so much discussion can happen around a single attribute ;) One thing I am still unclear of is what credentials are being sent when a user uses either crossorigin=anonymous for local requests or crossorigin=use-credentials for CORS requests? Are these specific HTTP headers that are set or, not set?

[11:10:21.0000] <schalkneethling>
Ah, I believe I have found the details on this https://html.spec.whatwg.org/#concept-media-load-resource

[11:10:35.0000] <schalkneethling>
proceeding to read the details

[11:43:41.0000] <Domenic>
https://twitter.com/domenic/status/643851648461369344

[13:50:09.0000] <JonathanNeal>
Thanks Domenic, just made a pull for the ul typo, hope I got it right https://github.com/whatwg/html/pull/146

[13:50:30.0000] <Domenic>
JonathanNeal: LGTM! :)

[13:50:53.0000] <caitp>
looks right to me

[13:50:55.0000] <Domenic>
Hmm are you in the acks yet?

[13:51:08.0000] <JonathanNeal>
Who me? what are the acks?

[13:51:19.0000] <Domenic>
Acknowledgments, heh.

[13:55:17.0000] <JonathanNeal>
Don’t know about them. Maybe setup a CONTRIBUTING.md doc?

[13:55:25.0000] <JonathanNeal>
I could make a pull request for that too :)

[13:56:36.0000] <JonathanNeal>
I have this rather generic one I’ve assembled, for example: https://github.com/jonathantneal/postcss-partial-import/blob/master/CONTRIBUTING.md

[13:57:28.0000] <Domenic>
JonathanNeal: in the past annevk has preferred keeping things in the readme so people just have to read that. Which makes sense to me. I agree the adding-yourself-to-the-acks should be noted though. Would be happy for you to do a PR for that :)

[13:58:05.0000] <JonathanNeal>
Yea, but CONTRIBUTING.md gets put at the top of every new issues page, look: https://github.com/jonathantneal/postcss-partial-import/issues/new

[13:58:13.0000] <JonathanNeal>
“Please review the guidelines for contributing to this repository.”

[13:58:19.0000] <Domenic>
sure, but nobody actually sees that :P

[13:59:17.0000] <JonathanNeal>
I do :( and it can be a link in the README.md as well, just link you can link to your license from there. Don’t see a LICENSE.md.

[13:59:29.0000] <JonathanNeal>
s/just link/just like

[14:00:03.0000] <Domenic>
license is in the spec along with attributions

[14:00:07.0000] <JonathanNeal>
Would you like additions to the acknowledgements as a separate commit?

[14:00:16.0000] <Domenic>
Sure, that would be great

[14:00:51.0000] <JonathanNeal>
These are also things to put in CONTRIBUTING.md. Then when you want things formatted a certain way you just ask them to modify their commit to follow it. No repeating instructions as much as pointing.

[14:01:12.0000] <Domenic>
We prefer README.md as a location for those instructions.

[14:01:31.0000] <JonathanNeal>
Sure. </sell>

[14:05:14.0000] <Domenic>
JonathanNeal: oh, I'm sorry, I misread. One commit please...

[14:06:30.0000] <Domenic>
I can squash it

[15:38:23.0000] <chimeno>
Good project! I'll try to contribute

[15:40:31.0000] <Domenic>
:)

[15:56:00.0000] <Domenic>
Trying to generate a html diff for annevk's fetch patch is really heating up my CPU

[16:48:15.0000] <JonathanNeal>
TabAtkins: http://jonathantneal.github.io/postcss-nesting/ a live demo of how I think you told me @nest should work, alongside custom selectors and custom properties

[16:48:55.0000] <TabAtkins>
JonathanNeal: @nest requires an & in the selector.


2015-09-16
[17:02:13.0000] <JonathanNeal>
TabAtkins: Okay, like this now?

[17:02:40.0000] <TabAtkins>
Yes.

[17:04:18.0000] <JonathanNeal>
Hurray!

[17:08:22.0000] <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?

[17:15:21.0000] <TabAtkins>
Krinkle: Correct, it's a direct result of that chat.

[17:16:05.0000] <Krinkle>
Exciting :)

[17:16:45.0000] <Krinkle>
I'm curious if you have any <s>bikeshed</s> advice on what a polyfill would look like.

[17:17:05.0000] <Krinkle>
Give me your best/worst :D

[17:17:44.0000] <JonathanNeal>
document.addEventListener('DOMContentLoaded', Promise.resolve); ?

[17:17:57.0000] <Krinkle>
JonathanNeal: The problem is not knowing whether the event already fired.

[17:18:00.0000] <Krinkle>
Async code

[17:18:32.0000] <JonathanNeal>
document.ready = new Promise(function (resolve) { document.addEventListener('DOMContentLoaded', resolve); }); ?

[17:18:53.0000] <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)

[17:19:17.0000] <Krinkle>
JonathanNeal: That code will be pending indefinitely if run after the event already fired.

[17:20:40.0000] <JonathanNeal>
Krinkle: is `readyState` part of the official API?

[17:21:13.0000] <TabAtkins>
I think it is?

[17:22:07.0000] <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.

[17:22:16.0000] <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.

[17:22:26.0000] <TabAtkins>
Yes, readyState is specified on Document in HTML.

[17:22:41.0000] <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.

[17:23:11.0000] <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.

[17:23:48.0000] <JonathanNeal>
Sorry that came twice, irccloud told me the previous one was not sent.

[17:50:08.0000] <Krinkle>
JonathanNeal: Hm.. yeah. I suppose it is relatively straight forward with dom ready

[17:50:14.0000] <Krinkle>
JonathanNeal: What about window.onload though?

[17:50:42.0000] <Krinkle>
I haven't found a way to do that short using performance.timing.loadEventEnd – which isn't very available yet.

[17:51:11.0000] <Krinkle>
or loadEventStart I suppose

[17:51:12.0000] <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

[17:56:39.0000] <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.

[17:57:03.0000] <Domenic>
Why not just load the polyfill script in your <head>

[17:58:02.0000] <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.

[17:58:50.0000] <Krinkle>
E.g. imagine the next version of google analytics or jquery requiring you put something in <head>

[17:59:48.0000] <JonathanNeal>
Yea, it’s unlikely. It was hard enough for html5shiv.

[18:01:14.0000] <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

[18:01:14.0000] <Krinkle>
main page.

[18:02:12.0000] <Domenic>
Sure, I thought you were talking about a polyfill, not a library.

[18:03:01.0000] <JonathanNeal>
But a polyfill has to be willing to work with what it has, and can’t guaruntee markup position.

[18:15:18.0000] <gsnedder1>
/me wonders if he's an idiot or if he's found a bug in AAA

[18:26:40.0000] <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.

[18:27:12.0000] <Krinkle>
Though yeah,ideally the polyfill would be embeddable as small micro library in any other library that needs it.

[18:27:23.0000] <JonathanNeal>
They need something that, to borrow an expression, does the right thing.

[18:28:24.0000] <TabAtkins>
JonathanNeal: You don't want "complete" (that's the load event), you want "interactive" (that'd DOMContentReady).

[18:28:40.0000] <TabAtkins>
JonathanNeal: You don't want "complete" (that's the load event), you want "interactive" (that'd DOMContentReady).

[18:28:44.0000] <JonathanNeal>
^ yes, as referenced in the stackoverflow I shared.

[18:28:49.0000] <TabAtkins>
Ah, sorry, didn't read.

[18:29:08.0000] <JonathanNeal>
My fault for mispeaking to begin with.

[18:31:03.0000] <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.

[18:31:10.0000] <JonathanNeal>
^ https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState

[18:31:31.0000] <Krinkle>
JonathanNeal: but those relate to the html payload, not the subresources.

[18:31:43.0000] <Krinkle>
window load, not document read/load

[18:31:54.0000] <JonathanNeal>
Read the definition for “complete” in that MDN link I just shared.

[18:32:09.0000] <Krinkle>
Interesting

[18:32:19.0000] <Krinkle>
I guess I was thrown off because it's on the document

[18:32:37.0000] <Krinkle>
cool :)

[18:33:20.0000] <Krinkle>
DOMComplete in Nav Timing is not the same as document.readyState=complete, then.

[18:33:57.0000] <Krinkle>
Hm.. the spec describes it as when readyState reaches "complete"

[18:34:04.0000] <Krinkle>
/me does some field tests

[18:34:12.0000] <MikeSmith>
Domenic: have at it https://github.com/whatwg/html-build/commit/a2135b8e7f136138edd48c9cfb980f585c683243

[18:36:49.0000] <gsnedders>
Nope. no bug in the AAA.

[18:36:53.0000] <gsnedders>
I'm just an idiot.

[18:38:19.0000] <JonathanNeal>
Krinkle: what are the two events you want? document.ready and ?

[18:38:33.0000] <Krinkle>
DOMContentLoaded and window.onload

[18:39:24.0000] <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.

[18:40:10.0000] <JonathanNeal>
The name of the Promise property, I mean. Just best guess.

[18:40:15.0000] <JonathanNeal>
document.ready and document.load ?

[18:55:40.0000] <Krinkle>
Yeah, though I can imagine there would be confusion.

[18:55:55.0000] <Krinkle>
Taking it off window seems nice, though I'm not sure why or if that's inline with other things happening in dom

[18:56:02.0000] <Krinkle>
http://codepen.io/Krinkle/pen/pjgGEY?editors=001

[18:57:18.0000] <JonathanNeal>
Krinkle: https://gist.github.com/jonathantneal/fba8689eaa288aeee11b

[19:00:15.0000] <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.

[19:00:53.0000] <Krinkle>
Yeah, once you understand.

[19:01:00.0000] <Krinkle>
I can't believe I never understood readyState until now

[19:01:42.0000] <Krinkle>
JonathanNeal: nit pick, but I believe that leaves the handler of interactive behind if complete is reached

[19:02:18.0000] <Krinkle>
may be pass an array of regex instead.

[19:02:35.0000] <Krinkle>
or*

[19:02:42.0000] <JonathanNeal>
Um, no it should fire even if complete is reached first.

[19:03:16.0000] <JonathanNeal>
You could run that code in your browser right now and your window would be complete and document.interactive would also be resolved.

[19:03:27.0000] <Krinkle>
Yes

[19:03:53.0000] <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

[19:04:36.0000] <Krinkle>
/me spent 8 hours doing code review today.

[19:05:09.0000] <JonathanNeal>
Yes, fixed.

[19:06:00.0000] <Krinkle>
nice

[19:06:04.0000] <MikeSmith>
Krinkle: 8 hours of code review sounds grim

[19:06:22.0000] <Krinkle>
My brain practically runs JS native now

[19:08:19.0000] <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.

[19:08:42.0000] <Krinkle>
I'm letting in sink in. It's too simple.

[19:08:56.0000] <Krinkle>
I demand an uglier implementation

[19:10:15.0000] <Krinkle>
So yeah, ES7(array) and ES6(Promise) aside, I'm thinking how far back this will run in browsers.

[19:11:04.0000] <Krinkle>
Down to say IE8 (no further)

[19:11:13.0000] <Krinkle>
attachEvent naturally, but that's simple

[19:14:42.0000] <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

[19:37:42.0000] <JonathanNeal>
mmhmm

[19:59:15.0000] <Domenic>
I agree with zcorpan_ that we should not do onload, just DOMContentLoaded.

[21:58:23.0000] <Krinkle>
JonathanNeal: Hm.. should that event listener be for readystatechange instead of DOMContentLoaded at https://gist.github.com/jonathantneal/fba8689eaa288aeee11b ?

[21:58:54.0000] <JonathanNeal>
What are you talking about, it is! :P

[22:02:20.0000] <JonathanNeal>
Thanks Krinkle

[22:04:13.0000] <Krinkle>
JonathanNeal: I'm trying it out at the moment and find some issues.

[22:04:41.0000] <Krinkle>
So the assumption that DOMComplete/document.readyState=complete/window.onload are the same is incorrect.

[22:04:49.0000] <Krinkle>
It is correct in the sense that very little happens in the browser

[22:05:05.0000] <Krinkle>
However the userland is notably different because readyState=complete is before the loadEvent starts/ends

[22:05:21.0000] <Krinkle>
which means it can't be used for a lot of things, such as collecting performance.timing (my current usecase)

[22:05:53.0000] <Krinkle>
Because the last two properties (loadEventStart/End) would still be 0

[22:06:23.0000] <Krinkle>
Right now we use a mixture of $(window).on('load') and polling performance.timing.loadEventEnd in an interval loop

[22:06:48.0000] <JonathanNeal>
You mean readyState “complete” !== window.load?

[22:06:53.0000] <Krinkle>
Indeed

[22:07:01.0000] <Krinkle>
It's a little bit before it

[22:07:15.0000] <JonathanNeal>
Does “complete” fire after all the assets have loaded, like “load"?

[22:07:24.0000] <Krinkle>
I believe so, but I'm not sure.

[22:07:53.0000] <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

[22:09:20.0000] <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

[22:09:28.0000] <Krinkle>
I really want to get rid of that polling loop

[22:10:38.0000] <Krinkle>
before we loaded scripts asynchronously it was: $(window).on('load', function () {setTimeout(collectNavTiming); }); which reliably got everything.

[22:11:15.0000] <Krinkle>
http://codepen.io/Krinkle/pen/rOxRjm?editors=001

[22:12:30.0000] <JonathanNeal>
It makes sense that it might be one tick before the real onload.

[22:12:53.0000] <JonathanNeal>
If for no other reason that it happens “deeper”

[22:14:51.0000] <Krinkle>
It seems fragile to rely on the fact that setTimeout() from document readyState==complete is after window.onload callbacks finish

[22:14:57.0000] <Krinkle>
I'll give it a try and run it in some browsers

[22:55:48.0000] <annevk>
zcorpan_: https://bugzilla.mozilla.org/show_bug.cgi?id=1203404

[00:13:52.0000] <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?

[00:14:10.0000] <annevk>
MikeSmith: hmm, back in 30-60min or so

[00:14:42.0000] <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

[00:14:50.0000] <annevk>
MikeSmith: on the server that is

[00:17:02.0000] <annevk>
MikeSmith: alternatively I guess we change wattsi to just point to /link-fixup.js

[00:17:17.0000] <annevk>
MikeSmith: or maybe generate link-fixup.js just like it does for fragment-links.js

[00:20:02.0000] <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?

[00:36:57.0000] <JonathanNeal>
:facepalm:

[00:37:37.0000] <JonathanNeal>
^ re: do not cc the entire list

[00:41:54.0000] <zcorpan_>
JonathanNeal: ?

[00:42:49.0000] <JonathanNeal>
nvm :)

[00:48:11.0000] <annevk>
zcorpan_: yeah, you want to calculate them when the event object is created

[00:56:20.0000] <zcorpan_>
annevk: hmm yes that does make more sense

[00:58:32.0000] <zcorpan_>
/me looks at https://w3c.github.io/uievents/#interface-MouseEvent

[00:59:04.0000] <annevk>
zcorpan_: I think we really want to merge CSSOM into that

[00:59:17.0000] <annevk>
zcorpan_: it doesn't make much sense to define MouseEvent in two different places

[00:59:44.0000] <annevk>
MikeSmith: I ended up filing an issue against html-build to sort out the file duplication

[00:59:58.0000] <annevk>
MikeSmith: I've figured out how it could be fixed, just need agreement

[01:19:42.0000] <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

[01:50:24.0000] <annevk>
schalkneethling: data and blob URLs go through Fetch

[01:50:39.0000] <annevk>
schalkneethling: "mode is object" is about objectSrc

[01:50:51.0000] <annevk>
schalkneethling: afaik

[01:52:01.0000] <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?

[01:53:59.0000] <schalkneethling>
referring to this part: https://html.spec.whatwg.org/#concept-media-load-resource

[01:54:06.0000] <annevk>
schalkneethling: blob and data URLs, I think so yes

[01:54:30.0000] <schalkneethling>
and I guess a File object is a blob as well right?

[01:55:15.0000] <schalkneethling>
so essentially the Fetch algorithm will always follow the mode is remote path unless the objectSrc was set by JS

[01:55:20.0000] <annevk>
schalkneethling: a File is a subclass of Blob

[01:56:02.0000] <annevk>
schalkneethling: reading this I think that's the case, though admittedly it's not entirely clear to me either

[01:56:08.0000] <annevk>
schalkneethling: philipj would know

[01:56:34.0000] <philipj>
annevk: soemthing about Blob/File?

[01:56:40.0000] <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

[01:57:33.0000] <philipj>
If we're talking about media elements, then s/objectSrc/srcObject/g

[01:58:20.0000] <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

[01:58:38.0000] <schalkneethling>
so, it seems to state that is the media element is a URL it will go down remote else local

[01:59:20.0000] <schalkneethling>
so the question is, is the only way for it to not be a URL to set the objectSrc/srcObject via JS

[01:59:39.0000] <schalkneethling>
and that is the only way Fetch will ever follow the mode is local path

[02:01:13.0000] <schalkneethling>
philipj: referring to this part of the spec https://html.spec.whatwg.org/#concept-media-load-resource

[02:01:41.0000] <philipj>
schalkneethling: are you trying to implement srcObject in a browser, and if so which one?

[02:02:21.0000] <schalkneethling>
philipj: oh no :) just trying to wrap my mind around it and understand the crossorigin attribute's role here

[02:03:05.0000] <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

[02:03:32.0000] <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

[02:03:59.0000] <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

[02:04:17.0000] <schalkneethling>
agreed, so this point "If mode is object"

[02:04:24.0000] <annevk>
schalkneethling: well, only if your URLs are actually cross-origin does crossorigin="" have any effect

[02:04:41.0000] <philipj>
the spec now says "The resource described by the current media resource, if any, contains the media data. It is CORS-same-origin."

[02:04:44.0000] <annevk>
schalkneethling: if you just have same-origin URLs you can do anything you want and you won't need it

[02:05:18.0000] <schalkneethling>
oooh, I thought you needed to specify crossorigin=anonymous for same origin

[02:05:27.0000] <schalkneethling>
if you wanted to do stuff on a canvas

[02:05:45.0000] <schalkneethling>
does this mean, it will load subtitle tracks as well as long as those reside on the same origin

[02:06:31.0000] <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

[02:07:15.0000] <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

[02:07:31.0000] <schalkneethling>
but then the use case for anonymous becomes kinda foggy

[02:07:56.0000] <schalkneethling>
perhaps I do not understand what those credentials are?

[02:19:18.0000] <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

[02:20:30.0000] <schalkneethling>
so, crossorigin is not a concern when using either of those types as a source

[02:21:51.0000] <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

[02:22:17.0000] <schalkneethling>
so, that leaves anonymous which is a little dubious

[02:32:48.0000] <annevk>
schalkneethling: credentials are just cookies, that may have been set for the domain in question

[02:32:52.0000] <schalkneethling>
ah so srcObject is the type of object

[02:33:37.0000] <schalkneethling>
and currentSrc is the actual location of the data object

[02:34:43.0000] <JakeA>
annevk: are non-tag members welcome to comment on https://github.com/w3ctag/spec-reviews/issues/76?

[02:34:45.0000] <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"

[02:35:28.0000] <schalkneethling>
so in essence, anonymous is a security measure to prevent credentials/cookies leaking across domains

[02:37:10.0000] <annevk>
JakeA: well I'm not a member, so yes

[02:37:41.0000] <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?

[02:39:35.0000] <annevk>
JakeA: he wants something different from the current protocol

[02:39:48.0000] <annevk>
JakeA: what he wants is give me the best response for a given URL

[02:40:00.0000] <annevk>
JakeA: without knowing whether that requires credentials or not

[02:41:02.0000] <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

[02:41:12.0000] <annevk>
JakeA: he doesn't like it

[02:41:31.0000] <annevk>
JakeA: and I'm just pointing out that you'll have the same problem with anything the resource might vary on

[02:41:53.0000] <nox>
gsnedders: Aren't the isindex tests wrong?

[02:42:23.0000] <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.

[02:42:35.0000] <nox>
gsnedders: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cisindex%20action%3D%22x%22%3E

[02:43:07.0000] <nox>
Oh, document-fragment context.

[02:43:11.0000] <annevk>
JakeA: yeah, I don't think this is going to result in something, someone can write a library I suppose

[02:43:38.0000] <annevk>
JakeA: pretty easy to write a varyCredentialsFetch()

[02:43:43.0000] <zcorpan_>
nox: blink has dropped isindex special parsing, if you mean that

[02:44:25.0000] <nox>
zcorpan_: No I mean '<isindex action="x">' as a table fragment.

[02:44:47.0000] <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)

[02:46:50.0000] <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

[02:47:01.0000] <annevk>
JakeA: his claim about the proxy server is wrong though, I guess I should point that out

[02:47:29.0000] <zcorpan_>
nox: i don't follow. which test are you talking about?

[02:48:03.0000] <nox>
zcorpan_: https://github.com/html5lib/html5lib-tests/pull/67/files#diff-654b5264d16ae0fd0b3d27f971f2d57cR259

[02:48:04.0000] <JakeA>
Cheers!

[02:49:08.0000] <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.

[02:50:32.0000] <zcorpan_>
nox: it's not what gecko does, at least. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3634

[02:51:04.0000] <nox>
zcorpan_: I see "Pop that form element off the stack of open elements." for "form" start tag in "in table" insertion mode.

[02:51:42.0000] <nox>
But that's not the code path that code takes, AFAICT.

[02:51:50.0000] <zcorpan_>
<table><isindex> (non-fragment) is another interesting case

[02:51:52.0000] <nox>
zcorpan_: My Safari does as in the test.

[02:53:16.0000] <zcorpan_>
yeah

[02:54:05.0000] <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?

[02:54:06.0000] <zcorpan_>
for <table><isindex> webkit foster-parents the form and pops the form so the hr is a sibling

[02:54:40.0000] <nox>
zcorpan_: "If foster parenting is enabled and target is a table, tbody, tfoot, thead, or tr element:"

[02:54:55.0000] <nox>
zcorpan_: But target is not a table element, right?

[02:55:53.0000] <zcorpan_>
nox: are you discussing the <table>.innerHTML = '<isindex>' case?

[02:56:12.0000] <nox>
zcorpan_: Yes.

[02:56:19.0000] <schalkneethling>
so, you could do a cross-origin fetch and set crossorigin=anonymous and that way cookies are not shared with the third party

[02:57:30.0000] <schalkneethling>
so anonymous means make anonymous cross-origin requests and use-credentials identifies you to the third party by sharing credential cookies

[03:00:55.0000] <schalkneethling>
BTW, thanks a million for all your assistance so far

[03:01:20.0000] <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)

[03:02:19.0000] <schalkneethling>
and only if you use "use-creentials" not "anonymous"

[03:03:08.0000] <annevk>
right

[03:03:12.0000] <schalkneethling>
if set to anonymous it will not use these credentials

[03:03:21.0000] <schalkneethling>
so if they are required, the requst will fail

[03:03:31.0000] <schalkneethling>
*request

[03:03:43.0000] <schalkneethling>
ok, I reckon I am getting to grips with this ;)

[03:03:45.0000] <annevk>
maybe, depends on how the server responds

[03:04:03.0000] <schalkneethling>
sure

[03:04:47.0000] <zcorpan_>
nox: /override target/ is only set in AAA, afaict, and that does not apply here

[03:05:06.0000] <zcorpan_>
nox: so target is the current node, which is <html> in the fragment case, right?

[03:05:13.0000] <nox>
zcorpan_: Yes.

[03:05:37.0000] <zcorpan_>
so many things to keep track of in the html parser :-(

[03:06:54.0000] <zcorpan_>
nox: ok so then "Let adjusted insertion location be inside target, after its last child (if any)."

[03:08:50.0000] <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

[03:10:45.0000] <zcorpan_>
i suppose you can get there with <table>.innerHTML = '<tbody><p>'

[03:12:18.0000] <nox>
zcorpan_: Yes.

[03:12:37.0000] <nox>
zcorpan_: Are you going to take care of it?

[03:14:52.0000] <zcorpan_>
nox: i can PR the test, sure

[03:17:13.0000] <schalkneethling>
annevk: so this all then relates to https://fetch.spec.whatwg.org/#http-access-control-allow-credentials

[03:18:37.0000] <annevk>
schalkneethling: it does yes, it maps to https://fetch.spec.whatwg.org/#concept-request-credentials-mode as I mentioned earlier

[03:19:04.0000] <schalkneethling>
ah, must have missed that

[03:19:05.0000] <schalkneethling>
thanks

[03:19:32.0000] <nox>
zcorpan_: Thanks.

[03:22:40.0000] <zcorpan_>
nox: https://github.com/html5lib/html5lib-tests/pull/68

[03:30:46.0000] <nox>
Cool.

[03:35:11.0000] <annevk>
zcorpan_: nox: also need to figure out <menuitem> at some point

[03:35:16.0000] <annevk>
zcorpan_: nox: whether it should remain void

[04:14:11.0000] <MikeSmith>
annevk: back now

[04:14:19.0000] <MikeSmith>
was out to dinner and such with N

[04:15:02.0000] <MikeSmith>
annevk: is the file/symlink thing resolved for now? or you still need me to do something?

[04:15:36.0000] <MikeSmith>
btw, the whatwg logo now has a permanent IPFS hash

[04:15:42.0000] <MikeSmith>
http://ipfs.pics/pic.php?id=QmbvGcNxAgVDpUBccHnNdxhj5VFaSaPgSXqLsEkj4wWL2i

[04:16:27.0000] <MikeSmith>
whatwg ye shall hereby be called QmbvGcNxAgVDpUBccHnNdxhj5VFaSaPgSXqLsEkj4wWL2i for posterity

[04:18:16.0000] <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

[04:19:12.0000] <MikeSmith>
and so if ipfs.pics goes away, you can still address it by that same hash from any other place that has it

[04:22:59.0000] <MikeSmith>
annevk: also if/when you have a moment, maybe reply to this tweet https://twitter.com/tjconceptdk/status/644066686342164480

[04:23:51.0000] <MikeSmith>
he seems like a clueful guy who would genuinely appreciate the info

[04:24:47.0000] <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

[04:26:37.0000] <annevk>
schalkneethling: did I not point you to https://github.com/whatwg/html/issues/95?

[04:26:51.0000] <annevk>
MikeSmith: what is IPFS?

[04:27:06.0000] <annevk>
MikeSmith: I filed an issue on whatwg/html-build, would appreciate your opinion

[04:27:47.0000] <schalkneethling>
ah, so it is in process

[04:28:22.0000] <MikeSmith>
IPFS is an amibitious plan to create permanance/persistence for the Web in the face of domains expiring and people abandoing sites, etc.

[04:29:00.0000] <annevk>
MikeSmith: replied to the tweet

[04:29:09.0000] <MikeSmith>
it works in part by assigning hashes to the state of each particular resource at any particular time

[04:29:19.0000] <annevk>
MikeSmith: oh my

[04:30:27.0000] <MikeSmith>
https://ipfs.io/#how-it-works

[04:30:48.0000] <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."

[04:32:03.0000] <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

[04:32:26.0000] <MikeSmith>
anyway, I will look at the issue

[04:45:11.0000] <annevk>
MikeSmith: could you merge WHATWG -> HTML - <img> into WHATWG -> HTML?

[04:45:39.0000] <annevk>
MikeSmith: or perhaps it's best to simply close it as well and transfer the bugs?

[04:49:51.0000] <MikeSmith>
annevk: yeah I think we should move the bugs and then close it

[04:49:53.0000] <MikeSmith>
I can do that

[04:50:02.0000] <MikeSmith>
zcorpan is OK with this?

[04:50:06.0000] <annevk>
oh cool

[04:50:11.0000] <annevk>
I haven't asked, I assume so

[04:50:16.0000] <zcorpan>
wat?

[04:50:39.0000] <annevk>
zcorpan: closing HTML - <img> component and moving the remaining bugs to the HTML component

[04:50:41.0000] <MikeSmith>
zcorpan: we transfer W3C bugzilla HTML <img> bugs to HTML componeentn

[04:52:08.0000] <zcorpan>
ok sure

[04:52:08.0000] <zcorpan>
but why

[04:52:29.0000] <zcorpan>
easier for other people to find the bugs?

[04:52:38.0000] <annevk>
zcorpan: yeah

[04:52:47.0000] <annevk>
zcorpan: they're not linked from the specification currently for instance

[04:56:03.0000] <zcorpan>
ok

[05:04:31.0000] <schalkneethling>
annevk: would appreciate feedback on this ~ https://sneethling.pastebin.mozilla.org/8846545

[05:04:32.0000] <schalkneethling>
thx!

[05:06:46.0000] <annevk>
schalkneethling: the Fetch standard is not in process

[05:06:51.0000] <annevk>
schalkneethling: integration into HTML is

[05:06:58.0000] <schalkneethling>
aha, my bad

[05:07:03.0000] <schalkneethling>
will update

[05:07:30.0000] <annevk>
use-URL-credentials is not code

[05:07:52.0000] <schalkneethling>
yeah, I am using that to liberally I realized ;p

[05:08:25.0000] <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

[05:08:27.0000] <annevk>
not a Fetch header, just a header

[05:08:46.0000] <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."

[05:10:53.0000] <schalkneethling>
thanks MikeSmith

[05:14:51.0000] <schalkneethling>
other than those two points, looking good annevk?

[05:15:43.0000] <annevk>
I guess

[05:15:53.0000] <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?

[05:16:17.0000] <schalkneethling>
hmmm, sounds like there are some things you are not sure about

[05:16:27.0000] <annevk>
Ms2ger: seems reasonable

[05:16:37.0000] <Ms2ger>
Great, thanks

[05:17:21.0000] <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.

[05:18:06.0000] <schalkneethling>
well, it would be aimed at web developers using the video element and perhaps not being familiar with the crossorigin attribute

[05:18:36.0000] <schalkneethling>
and a little broad overview of how it forms part of the larger framework of loading resources

[05:41:55.0000] <MikeSmith>
dang we were getting close to having only 300 open bugs before

[05:42:05.0000] <MikeSmith>
now 318

[05:42:07.0000] <MikeSmith>
https://www.w3.org/Bugs/Public/buglist.cgi?component=HTML&list_id=59532&product=WHATWG&resolution=---

[05:43:39.0000] <annevk>
MikeSmith: you ruined it!

[05:45:52.0000] <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

[05:46:11.0000] <MikeSmith>
I blame you and zcorpan_

[05:46:27.0000] <annevk>
beverloo: even on OS X?

[05:46:28.0000] <MikeSmith>
beverloo: glad to hear that

[05:46:35.0000] <beverloo>
yes, annevk

[05:46:51.0000] <beverloo>
Chrome OS keeps it as part of the OS, Android uses the OS' notification center, it's gone on Win/Mac/Linux

[05:47:03.0000] <annevk>
beverloo: how does that work? You simply don't integrate with the OS?

[05:47:08.0000] <beverloo>
usage statistics were in the realms of "it pretty much doesn't exist"

[05:47:13.0000] <MikeSmith>
I think the notification center approach is bad UX in practice

[05:47:21.0000] <beverloo>
yes, we found it to not work

[05:47:53.0000] <beverloo>
annevk, indeed. We're keeping our own toasts for now and won't (yet) move them to the OS' notification center after

[05:48:29.0000] <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

[05:48:33.0000] <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.

[05:48:42.0000] <beverloo>
(which is not necessarily a bad thing)

[05:48:52.0000] <Domenic>
Well, OK, now that you said your last line it sounds much more reasonable

[05:49:07.0000] <beverloo>
Domenic, we're actually looking at that, especially with Windows 10's new notification center :)

[05:49:16.0000] <Domenic>
\o/

[05:53:17.0000] <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

[05:53:23.0000] <MikeSmith>
my tabs

[05:53:32.0000] <annevk>
Domenic: so if you're okay with path-absolute URLs, no changes to Wattsi would be required...

[05:53:40.0000] <annevk>
Domenic: we'd just update source

[05:54:08.0000] <beverloo>
MikeSmith, agreed

[05:54:12.0000] <beverloo>
I can't say much about it, but we're talking :)

[05:54:18.0000] <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)

[05:54:22.0000] <MikeSmith>
beverloo: k

[05:59:17.0000] <Domenic>
annevk: ah that's true. I guess I am OK with that.

[06:02:25.0000] <annevk>
Domenic: combined with your patch to remove the images.whatwg.org thing I think we're all set then

[06:02:31.0000] <annevk>
Domenic: guess I'll wait for that to land first

[06:50:20.0000] <gsnedders>
nox: I think the vast majority are right. It's not impossible one or two slipped through.

[06:51:52.0000] <annevk>
MikeSmith: was https://github.com/validator cloning HTML intentional?

[06:53:39.0000] <MikeSmith>
yeah that was just for me to create a PR against mkwst's fork

[06:54:00.0000] <MikeSmith>
I will delete that validator fork now

[07:01:54.0000] <MikeSmith>
sento time; back in ~2hrs

[07:09:22.0000] <nox>
gsnedders: One was wrong, zcorpan made a PR.

[07:16:49.0000] <annevk>
Anyone use @htmlstandard recently? Just got an email from Twitter about potential account abuse...

[07:18:14.0000] <gsnedders>
nox: jgraham merged it hours ago :P

[07:18:33.0000] <nox>
Hah, didn't even notice.

[07:22:47.0000] <Domenic>
annevk: it was me, trying to add it to tweetdeck

[07:23:29.0000] <nox>
gsnedders: Are some svg attributes supposed to be dropped?

[07:24:00.0000] <gsnedders>
nox: Yes. Loads were removed ages from the spec.

[07:24:04.0000] <nox>
Never mind, completely misread the step.

[07:24:16.0000] <nox>
Is filterres special?

[07:25:14.0000] <gsnedders>
special how?

[07:25:25.0000] <nox>
Appearing out of nowhere like a wild pokémon.

[07:25:53.0000] <nox>
gsnedders: https://github.com/html5lib/html5lib-tests/blob/master/tree-construction/tests11.dat#L155

[07:26:29.0000] <gsnedders>
I probably fucked up one of the merges. :)

[07:26:50.0000] <gsnedders>
nox: fucked up the merge.

[07:27:03.0000] <nox>
gsnedders: Just not here, I guess?

[07:27:07.0000] <nox>
Not just here*

[07:28:47.0000] <nox>
gsnedders: https://github.com/html5lib/html5lib-tests/pull/69

[07:28:48.0000] <gsnedders>
nox: tl;dr: it's an attribute that got dropped

[07:30:55.0000] <nox>
gsnedders: TL;DR LGTM. :P

[07:31:11.0000] <gsnedders>
nox: soz, trying to do ten things at once :P

[07:31:22.0000] <nox>
Oh, or was the test supposed to check that filterres doesn't become filterRes?

[07:32:10.0000] <Ms2ger>
Yeah

[07:32:19.0000] <nox>
Ms2ger: Fixed.

[07:33:08.0000] <gsnedders>
hmm, yeah, we probably ought have tests checking they don't get changed

[07:33:14.0000] <gsnedders>
bah, I did the wrong thing in the merge, I guess.

[07:33:24.0000] <gsnedders>
Because Blink just removed them from the tests altogether

[07:33:39.0000] <gsnedders>
I'd suggest having the not-converted attributes in a different tests, though.

[07:34:13.0000] <nox>
gsnedders: I leave that as an exercice to the next person. :P

[07:46:25.0000] <ccardona-work>
Good morning/afternoon/evening WHATWG crew o/

[07:55:13.0000] <annevk>
I was thinking, we could have something related to a kitchen sink as logo for @htmlstandard

[08:02:17.0000] <Ms2ger>
s/could/MUST/ :)

[08:31:01.0000] <annevk>
Domenic: I think there's a few places where attributes have states, and then whatever is the current state is called the mode...

[08:31:46.0000] <Domenic>
annevk: I haven't seen mode anywhere else

[08:32:46.0000] <Domenic>
e.g. "If an HTML element's translate attribute is in the yes state"

[08:33:01.0000] <Domenic>
maps to a *separate* concept of translation mode

[08:33:09.0000] <Domenic>
but the attribute has a state, not a mode

[08:33:27.0000] <Domenic>
And there's an explicit mapping between the attribute states and the translate modes

[08:33:33.0000] <annevk>
"mode being the current state of the element's crossorigin content attribute"

[08:33:54.0000] <Domenic>
yeah the current spec has this confusion, i agree

[08:33:57.0000] <Domenic>
but it is very confusing

[08:34:18.0000] <Domenic>
and doesn't match any other attributes

[08:34:36.0000] <annevk>
I guess I can just rename it all to state, I don't care strongly

[08:35:02.0000] <Domenic>
yes please :)

[08:35:47.0000] <annevk>
Domenic: before I do that, did you review the changes? If so I'll rebase first

[08:36:40.0000] <annevk>
Meh never mind

[08:37:26.0000] <Domenic>
annevk: yeah looks good

[08:48:27.0000] <annevk>
Domenic: heh, my own noexport patch made rebasing harder

[08:48:43.0000] <annevk>
Domenic: anyway, rebasing is done, I didn't squash yet since I guess we are not done yet...

[08:51:30.0000] <gsnedders>
Ergh. I hate how practically impossible it is to state what meta elements have any affect on SEO.

[08:51:47.0000] <Domenic>
annevk: sorry, will try to finish review within the next few hours...

[08:52:13.0000] <annevk>
Domenic: no worries

[09:06:01.0000] <annevk>
"Cookies respect SOP by design" oh public-webappsec...

[09:41:42.0000] <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.

[09:42:03.0000] <Krinkle>
And in fact it also has readyState (property) incorrect, it uses "loading" and "loaded". Not interactive or complete. And it

[09:42:14.0000] <Krinkle>
's loaded matches "interactive"

[09:43:59.0000] <Krinkle>
Progress at http://codepen.io/Krinkle/pen/rOxRjm?editors=001

[09:45:05.0000] <Krinkle>
or here https://gist.github.com/Krinkle/fc0b4d4626f2409219ee

[09:55:30.0000] <Matt5ander5>
test

[10:08:34.0000] <annevk>
Domenic: what about https://github.com/whatwg/html/pull/144#issuecomment-140643963?

[10:09:14.0000] <annevk>
Krinkle: so are you planning on working on source maps? Since we have this repo...

[10:23:58.0000] <Krinkle>
annevk: I'm waiting for reply from the mailing list

[10:24:19.0000] <annevk>
Krinkle: source map mailing list?

[10:24:24.0000] <Krinkle>
Yeah

[10:24:28.0000] <Krinkle>
They don't seem to be interested.

[10:25:08.0000] <Krinkle>
https://groups.google.com/forum/#!topic/mozilla.dev.js-sourcemap/SD8sZ_7VFpw

[10:27:10.0000] <Krinkle>
annevk: I suppose we can delete the repo fo rnow

[10:28:05.0000] <JonathanNeal>
Krinkle: Andoird 2.3 is still a thing

[10:28:07.0000] <JonathanNeal>
?

[10:28:28.0000] <annevk>
Krinkle: maybe that's better so nobody gets the impression we step on their turf

[10:28:40.0000] <Krinkle>
annevk: Yeah, fine by me :)

[10:28:59.0000] <Krinkle>
JonathanNeal: Enough of a thing that we support it.

[10:29:18.0000] <Krinkle>
And adding a primitive like this requires support there, otherwise random things will start to fail there.

[10:29:45.0000] <Krinkle>
We've dropped support for IE6 and IE7 in 2014

[10:29:52.0000] <JonathanNeal>
Oh good.

[10:30:04.0000] <Krinkle>
for JS runtime at least (we "support" that fact that it isn't supported by cutting the mustard)

[10:30:23.0000] <Krinkle>
We still support them for basic stylesheet and content accessibility

[10:30:54.0000] <Krinkle>
Because IE is very UX intrusive when it comes to exceptions.

[10:31:26.0000] <annevk>
Krinkle: removed, let me know if you need it back or want to work on something else

[10:31:55.0000] <Krinkle>
JonathanNeal: It's been a while since I evaluated Android usage though. Let me take a peek

[10:32:17.0000] <Krinkle>
JonathanNeal: This is last month's Wikimedia global page-view traffic browser usage: https://docs.google.com/spreadsheets/d/1n9FhSqcBGM9iKXrlHsP0EZI0gU89Rmz5m51uglUGVjs/edit#gid=0

[10:35:33.0000] <Krinkle>
Traditionally our cut off for dropping support is about 0.1%

[10:35:59.0000] <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.

[10:39:23.0000] <Krinkle>
Looks like Android 2 is at 0.69% (109M views in August '15)

[10:51:50.0000] <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)

[10:52:05.0000] <JonathanNeal>
The one from your gist?

[10:52:07.0000] <Krinkle>
And have it be defined as window.onload ->setTimeout->resolve.

[10:52:40.0000] <Krinkle>
Can't use readystatechange because Android 2.3. And I don't see any way to determine whether readyState=complete in Android

[10:52:57.0000] <Krinkle>
it only implements the non-standard readyState "loaded" which an equivelant to "interactive"

[10:53:38.0000] <Krinkle>
in Android the current code in the gist just remained unresolved.

[10:54:35.0000] <JonathanNeal>
What about using the window.onload event then?

[10:54:47.0000] <Krinkle>
Well, I can only do that if it hasn't happend yet

[10:54:54.0000] <Krinkle>
I don't have a way to determine whether it has

[11:00:04.0000] <JonathanNeal>
Unrelated, these new CSS syntax goodies like `@nest` rules, `:matches`, and `@apply` really chip away at the usability of Sass.

[11:00:50.0000] <TabAtkins>
That's the point, yeah.

[11:01:22.0000] <TabAtkins>
Preprocessors exist largely because CSS hasn't been extensible.  As we fix that, the set of things that preprocessors provide will shrink.

[11:01:45.0000] <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.

[11:02:33.0000] <gsnedders>
Does JS really make more sense than preprocessing the CSS?

[11:08:31.0000] <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." :)

[11:09:37.0000] <TabAtkins>
gsnedders: It's easy than a build step. That's basically ReSpec's value proposition over Bikeshed.

[11:11:18.0000] <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.

[11:11:34.0000] <gsnedders>
I don't even know how to fix most of that, precicely because legacy.

[11:29:36.0000] <Domenic>
This fetch change is so good, look at all this extra precision being added.

[11:36:55.0000] <wanderview>
I wish I had time to review the fetch change

[12:00:01.0000] <Krinkle>
Hm.. interesting. So the pre* specs are together now in resource-hints. That's a nice simplification.

[13:37:16.0000] <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


2015-09-17
[22:59:03.0000] <MikeSmith>
heycam: If you're around, I have what I hope is a related to WebIDL use in the HTML spec that should be quick to answer

[22:59:15.0000] <heycam>
MikeSmith, hi! sure.

[22:59:28.0000] <MikeSmith>
heycam: ok, in https://html.spec.whatwg.org/multipage/infrastructure.html#safe-passing-of-structured-data

[22:59:47.0000] <MikeSmith>
or more specifically in https://html.spec.whatwg.org/multipage/infrastructure.html#internal-structured-cloning-algorithm

[23:00:01.0000] <MikeSmith>
the If input is an Object object

[23:00:09.0000] <MikeSmith>
the "If input is an Object object" case

[23:00:41.0000] <MikeSmith>
that should in fact be uppercase "Object", right?

[23:00:53.0000] <MikeSmith>
I mean it's right as-is

[23:01:05.0000] <MikeSmith>
it should not be lowercase "object"

[23:01:18.0000] <heycam>
MikeSmith, yes, I think it's right to be Object

[23:01:28.0000] <heycam>
since below that it says that those names are used to check against [[Class]]

[23:01:36.0000] <MikeSmith>
ok

[23:01:58.0000] <heycam>
mind you, [[Class]] doesn't exist any more in ES6

[23:02:00.0000] <MikeSmith>
lemme check I think there is once more instance I wanted to conform

[23:02:03.0000] <MikeSmith>
oh

[23:02:21.0000] <MikeSmith>
will we have to update the HTML spec then?

[23:02:24.0000] <MikeSmith>
with regard to that

[23:03:07.0000] <heycam>
yeah, it should.

[23:03:10.0000] <heycam>
/me wonders what to

[23:03:38.0000] <heycam>
I have loose language in the IDL spec like "if V is a Dat object, ..."

[23:03:41.0000] <heycam>
*Date

[23:03:51.0000] <heycam>
but I need to make that more precise

[23:03:56.0000] <MikeSmith>
hmm yah

[23:04:37.0000] <heycam>
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.prototype.tostring does checking for particular internal slots, to determine what to return from Object.prototype.toString

[23:04:57.0000] <MikeSmith>
/me looks

[23:05:28.0000] <heycam>
so to the extent that we need to do type checking of JS objects, maybe we should have some common definition that does the same checks

[23:05:49.0000] <MikeSmith>
yeah that would seem to make sense

[23:06:49.0000] <heycam>
another point is that newer objects like Map and Set get their appropriate Object.prototype.toString value from their @@toStringTag property

[23:07:13.0000] <MikeSmith>
so?

[23:07:42.0000] <heycam>
so specific checks like for [[MapData]] might be warranted there

[23:07:45.0000] <annevk>
zcorpan: do you not have Wattsi setup?

[23:08:00.0000] <MikeSmith>
heycam: ah ok

[23:08:19.0000] <MikeSmith>
wait wat is a "exotic String object"

[23:08:21.0000] <heycam>
then for all of the IDL-interface-typedef things, like ImageData, it's sufficient just to say "if input is an ImageData object"

[23:08:42.0000] <heycam>
as the IDL spec assumes that we can tell that an object is a platform object implementing a particular IDL interface

[23:08:44.0000] <MikeSmith>
ah yeah I see, that would be preferable

[23:08:49.0000] <MikeSmith>
yeah

[23:09:08.0000] <heycam>
but yeah a single algorithm "if an X is a Y object" that does all that would be helpful

[23:09:40.0000] <annevk>
MikeSmith: so I think we want to move structured cloning into IDL...

[23:09:44.0000] <MikeSmith>
I support any plan that pushes all the hard work to the WebIDL spec

[23:09:55.0000] <annevk>
MikeSmith: since it's an ECMAScript extension in part it doesn't really fit well in HTML

[23:10:01.0000] <MikeSmith>
annevk: yeah I think there is a note about that somewhere

[23:10:08.0000] <MikeSmith>
yup

[23:10:36.0000] <heycam>
probably makes sense yeah

[23:11:33.0000] <MikeSmith>
annevk: in the mean time it would be nice to clear away as many of the XXX comments in the source as we can. It's a minor thing but to me at least it's not very helpful to have the build just spit that list out at end every single time

[23:11:54.0000] <MikeSmith>
because in practice we then just ignore that list

[23:11:56.0000] <annevk>
MikeSmith: I would accept a PR that changes them to "TODO"

[23:12:29.0000] <MikeSmith>
OK well then the disappear completely and we never get back to fixing them

[23:12:33.0000] <annevk>
MikeSmith: my understanding is that XXX can be used while making edits, it should not be used for things that end up in a commit

[23:12:41.0000] <MikeSmith>
ah ok

[23:12:56.0000] <annevk>
MikeSmith: we should probably track TODO separately somehow, or file issues on them

[23:13:47.0000] <MikeSmith>
OK well then I would like to fix/remove the existing XXX ones that we can fix/remove, then after that, change the remaining ones to TODOs

[23:14:00.0000] <MikeSmith>
I can make a PR for that

[23:16:36.0000] <MikeSmith>
annevk: and maybe I can for that PR just make an xxx-removal branch, and then everybody reviews the existing XXX things and we all just push changes to the branch for any we have information for that we can resolve

[23:16:44.0000] <MikeSmith>
all work off the same branch

[23:17:22.0000] <MikeSmith>
OK>

[23:17:29.0000] <MikeSmith>
OK?

[23:18:41.0000] <annevk>
MikeSmith: sure

[23:19:11.0000] <annevk>
MikeSmith: got distracted, but that seems totally fine

[23:19:32.0000] <zcorpan>
annevk: no, haven't attempted yet

[23:20:41.0000] <annevk>
zcorpan: that might be a good idea, especially when supplying patches that are more than a typo fix

[23:21:21.0000] <zcorpan>
annevk: yes :-)

[00:08:29.0000] <MikeSmith>
zcorpan: several of those existing XXX comments seem to be in the source of the image section

[00:18:10.0000] <zcorpan>
MikeSmith: yeah

[00:39:04.0000] <annevk>
MikeSmith: so yeah, I looked at that Object thing and fixing it is kind of a rabbit hole

[00:39:29.0000] <annevk>
MikeSmith: I would be okay with just removing the XXX thing though and filing an issue on structured cloning

[00:45:43.0000] <MikeSmith>
aok

[00:45:53.0000] <annevk>
MikeSmith: btw, if I want to update Wattsi, what do I do? Just run build.sh and hope for the best?

[00:46:28.0000] <annevk>
MikeSmith: is DEFINES="-dUSEROPES -dLINES -dPARSEERROR -Px86_64" still needed with your fix?

[00:48:45.0000] <MikeSmith>
annevk: yeah it should just (re)compile. If it doesn't then that's a bug on whoever made the change that broke its build

[00:48:56.0000] <MikeSmith>
you can drop -Px86_64 now

[00:49:07.0000] <annevk>
MikeSmith: so one thing that would be great for you to host would be the email archives...

[00:49:39.0000] <annevk>
MikeSmith: that would substantially improve the status quo, though might be tricky

[00:50:30.0000] <MikeSmith>
if we host the email archives we want it at the some domain, no?

[00:50:53.0000] <MikeSmith>
I know we could rewrite the URLs

[00:52:35.0000] <annevk>
MikeSmith: yeah, ideally everything the same

[00:52:54.0000] <annevk>
MikeSmith: since DreamHost doesn't provide us with HTTPS, lists.whatwg.org is basically broken

[00:55:26.0000] <MikeSmith>
well I could host something experimentally first, either under https://sideshowbarker.net/ or I get another domain and cert

[00:55:41.0000] <MikeSmith>
or we transfer DNS for some domain to a host I get set up

[00:56:03.0000] <MikeSmith>
or subdomain of what.org

[00:56:19.0000] <MikeSmith>
ah yeah, so if we could do that for lists.whatwg.org yeah

[00:57:11.0000] <MikeSmith>
but the other thing is, we'd want to decide on what e-mail archiving software we want to use

[00:57:57.0000] <annevk>
whatwg/wattsi no longer being a fork made that somewhat hard

[00:58:03.0000] <MikeSmith>
rather than the old-fashioned one we had before, and the mailman thing or whatever it is that we have a w3c

[00:58:26.0000] <annevk>
if we use different software we'd have to setup redirects and such, no?

[00:58:44.0000] <MikeSmith>
ah you mean for the existing archives too

[00:58:51.0000] <MikeSmith>
yeah we would I guess

[00:58:57.0000] <annevk>
sounds painful

[00:59:03.0000] <MikeSmith>
yeah

[00:59:10.0000] <annevk>
I'm not opposed, but I'm not sure how complicated you'd want to make this

[00:59:23.0000] <MikeSmith>
no, I didn't understand what the goal was

[00:59:49.0000] <annevk>
basically to get lists.whatwg.org on the HTTPS train

[01:00:00.0000] <MikeSmith>
if the goal is to make the existing URLs to the archive actually work again I can definitely host that

[01:00:06.0000] <MikeSmith>
yeah

[01:00:11.0000] <MikeSmith>
so that's do-able

[01:01:02.0000] <MikeSmith>
> annevk: whatwg/wattsi no longer being a fork made that somewhat hard

[01:01:10.0000] <MikeSmith>
but you got it worked out OK?

[01:01:25.0000] <annevk>
yeah, just deleted what I had and then did it again

[01:01:29.0000] <MikeSmith>
k

[01:02:13.0000] <MikeSmith>
anyway right my biggest priority is that I want to get the changes to the build script landed

[01:02:40.0000] <MikeSmith>
then I will return to greater sanity and can think clearly about other stuff

[01:04:48.0000] <MikeSmith>
spending a lot of time writing bash/shell script stuff kind of messes with one's mind

[01:04:49.0000] <annevk>
yeah, this has no priority whatsoever, just seemed like a good task to sort out first, since that is actually something that is broken with our current server setup

[01:04:57.0000] <MikeSmith>
yeah agreed

[01:05:29.0000] <MikeSmith>
it will be cheaper and simpler to deploy come November of course

[01:05:37.0000] <MikeSmith>
as far as the cert setup

[01:06:01.0000] <annevk>
MikeSmith: yeah, hopefully that works out well

[01:06:37.0000] <MikeSmith>
I think it will. They met their goal for this month and seem to be on track with the plans for Nov

[01:06:41.0000] <annevk>
MikeSmith: would be great if we could migrate 1H of next year to avoid having to do the dance again, certificate lasts until July 2016 or so

[01:06:52.0000] <MikeSmith>
ah yeah

[01:07:24.0000] <annevk>
And I somewhat doubt DreamHost will have Let's Encrypt integration anytime soon, but who knows

[01:07:31.0000] <MikeSmith>
ah true

[01:09:21.0000] <MikeSmith>
so about that, anyway in general, I do not find it painful or onerous to maintain a full system from a VM with root

[01:10:02.0000] <MikeSmith>
I've run my own sites that way for long years now, including running an MTA (exim4), which is about as hairy as it gets

[01:10:41.0000] <zcorpan>
annevk: hmmm, img-environment-changes should have initiator "imageset" probably

[01:11:17.0000] <MikeSmith>
so if/when were to decide to move away from Dreamhost to running it all on a VM I think it could be manageable and I would be OK taking responsiblity for keeping it running and dealing with outages and what-not

[01:11:39.0000] <annevk>
zcorpan: did I cause a regression?

[01:13:42.0000] <zcorpan>
annevk: no, the old text didn't mention it in that algorithm. i can file a new bug

[01:17:02.0000] <zcorpan>
https://github.com/whatwg/html/issues/159

[01:17:42.0000] <annevk>
zcorpan: unless there's anything else I'll merge https://github.com/whatwg/html/commit/5ce1250e9832f2ae6fed4b6e8151a39be2a6dd78 into master

[01:18:19.0000] <zcorpan>
annevk: LGTM

[01:19:30.0000] <Ms2ger>
annevk, you'll have to close the issues manually, btw

[01:19:39.0000] <annevk>
Ms2ger: yeah I know

[01:20:37.0000] <MikeSmith>
annevk: I never made time to review it but will post-merge (on the off chance I notice something that nobody else noticed yet)

[01:23:42.0000] <annevk>
MikeSmith: thank you

[01:24:07.0000] <annevk>
MikeSmith: there is definitely things left to fix, in particular wording around response handling can be much improved still

[01:24:45.0000] <MikeSmith>
well for now it's really nice to have that landed

[01:31:21.0000] <annevk>
>23500 occurrences of "<code"

[01:31:45.0000] <annevk>
That makes annotating strings and byte sequences a little more involved than I hoped for

[01:45:07.0000] <Ms2ger>
Well this is not something I expected to see today: https://bugzilla.mozilla.org/show_bug.cgi?id=1205391

[01:53:20.0000] <annevk>
Ms2ger: it's amusing how much senior engineers "spam" attracts

[02:08:48.0000] <annevk>
It seems Fetch can't escape the jokes: https://twitter.com/kevinmarks/status/644430480364802048 https://twitter.com/maybekatz/status/643690173486620672

[02:08:55.0000] <annevk>
I'm not even sure whether I've seen that movie

[02:10:45.0000] <tantek>
annevk: it's a powerful reference

[02:13:17.0000] <JakeA>
I haven't seen it, but I feel like I have now

[02:40:18.0000] <annevk>
heycam|away: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28765 seems bogus, but I'm not sure...

[02:40:22.0000] <annevk>
heycam|away: do you know?

[02:40:28.0000] <annevk>
Ms2ger: you perhaps?

[02:42:49.0000] <jgraham>
Seems Ms2ger didn't want to help

[02:50:27.0000] <annevk>
:-(

[03:08:19.0000] <Ms2ger>
annevk, sup?

[03:15:19.0000] <Ms2ger>
annevk, seems like it could make sense if we're ever going to add more prefixed attributes to WorkerGlobalScope

[03:57:36.0000] <annevk>
Ms2ger: can you explain to me how they're different?

[03:59:29.0000] <Ms2ger>
annevk, how what's different?

[04:00:39.0000] <annevk>
Ms2ger: using implements vs inheritance for a global

[04:02:14.0000] <Ms2ger>
Inherited attributes aren't "own"

[04:03:27.0000] <Ms2ger>
So `var location = location` in a worker creates a shadowing own property initialized to undefined, and then sets it to itself

[04:06:09.0000] <annevk>
Ms2ger: https://heycam.github.io/webidl/#Global in step 2 it says consequential interfaces which includes inherited interfaces

[04:06:27.0000] <Ms2ger>
Really?

[04:07:24.0000] <Ms2ger>
I don't think A is a consequential interface of A

[04:08:09.0000] <annevk>
Ms2ger: yeah, I guess not, that seems somewhat confusing

[04:08:56.0000] <Ms2ger>
No opinion on whether it should

[05:26:15.0000] <annevk>
Ms2ger: do you know how Gecko's worker setup works?

[05:26:38.0000] <annevk>
Ms2ger: fixing the base URL thing is somewhat complicated since the specification sets up the environment before it actually starts fetching...

[05:27:54.0000] <Ms2ger>
annevk, vaguely. Have you seen khuey's presentation?

[05:28:15.0000] <annevk>
Ms2ger: I don't think it goes into this from memory, but it's been a while

[05:30:02.0000] <Ms2ger>
https://mxr.mozilla.org/mozilla-central/ident?i=GetOrCreateGlobalScope may point to related code?

[05:51:48.0000] <annevk>
http://www.w3.org/TR/workers/ o_O

[05:52:59.0000] <slvrbckt>
does anyone know if ReadableStream can be used to acheive what is described in this writeup? http://maxogden.com/a-proposal-for-streaming-xhr.html

[05:54:55.0000] <annevk>
slvrbckt: I think so, yes

[05:56:48.0000] <annevk>
I think I have a way to rewrite this worker thing... Not entirely sure it won't crash anything though

[05:58:03.0000] <slvrbckt>
 annevk: I'm having a hard time finding any good documentation on using ReadableStream, do you know of any good introductions to using it with large file downloads in the browser?

[05:59:00.0000] <annevk>
slvrbckt: does https://jakearchibald.com/2015/thats-so-fetch/#streams help?

[06:04:14.0000] <slvrbckt>
annevk: that does help, it's centered about text data, but I think it shouldn't be too hard to translate that to dealing with binary data

[06:05:55.0000] <annevk>
Ms2ger: so the way Hixie designed this basically requires overwriting the URL of the setting object later on...

[06:06:09.0000] <annevk>
Ms2ger: since a MessagePort object needs to be associated with a settings object upon creation

[06:06:27.0000] <annevk>
Ms2ger: and presumably MessagePorts need to be entangled before being handed back

[06:06:51.0000] <annevk>
Ms2ger: so you would either have to try to unravel all that or do this quick hack...

[06:06:51.0000] <Ms2ger>
Ugh, MessagePorts

[06:07:20.0000] <annevk>
There's also a bug in the spec where it entangles the MessagePort with the global object rather than the settings object

[06:07:33.0000] <annevk>
That's why I thought I could fix it initially, by just creating the settings object later

[06:08:26.0000] <annevk>
MikeSmith: I think rigo just advertized self-signed certificates on public-webappsec...

[06:08:43.0000] <annevk>
mkwst: will that list get moderation at some point?

[06:41:27.0000] <annevk>
Ms2ger: so... shared workers and redirects, how does that work?

[06:41:43.0000] <annevk>
Ms2ger: each time I get close to solving this, another problem pops up

[06:45:14.0000] <wanderview>
annevk: what kind of redirects?  worker scripts are restricted to same-origin, right?

[06:45:42.0000] <annevk>
wanderview: sure

[06:46:14.0000] <annevk>
wanderview: say you have /a/ redirecting to /b/, what is the base URL?

[06:46:36.0000] <annevk>
wanderview: what does new SharedWorker("/a/") vs new SharedWorker("/b/") do (and combinations on that theme)

[06:46:46.0000] <wanderview>
hmm, ok

[06:47:17.0000] <annevk>
Not really, it all looks ind of broken :-)

[06:48:50.0000] <Ms2ger>
annevk, yeah

[06:49:14.0000] <Ms2ger>
Let me quote from my lists of things to write tests for

[06:49:14.0000] <Ms2ger>
SharedWorker

[06:49:15.0000] <Ms2ger>
  > If worker global scope's location attribute represents an absolute URL

[06:49:15.0000] <Ms2ger>
  > that is not exactly equal to scriptURL, then throw a URLMismatchError

[06:49:15.0000] <Ms2ger>
  > exception and abort all these steps.

[06:49:15.0000] <Ms2ger>
  new SharedWorker("x"); new SharedWorker("x"); with x redirecting to y

[06:50:39.0000] <annevk>
Ms2ger: the whole WorkerLocation concept is kind of hand wavy designed too

[06:51:09.0000] <Ms2ger>
It does mention "after redirects", though, doesn't it?

[06:51:31.0000] <annevk>
Ms2ger: sure, but nowhere is it actually set

[06:51:47.0000] <Ms2ger>
Yeah

[06:51:51.0000] <Ms2ger>
Par for the course :)

[07:03:04.0000] <annevk>
Ms2ger: it seems you get distinct instances https://dump.testsuite.org/worker/sharedworker.html

[07:03:41.0000] <Ms2ger>
Lovely

[07:03:46.0000] <Ms2ger>
Not very surprising, but still

[07:03:56.0000] <annevk>
Ms2ger: maybe I should wait creating a new one until I get something back, see what happens then

[07:04:59.0000] <Ms2ger>
Ugh, hadn't even though about that

[07:18:06.0000] <annevk>
Ms2ger: doesn't seem to matter

[07:20:01.0000] <annevk>
Ms2ger: how can you even get a URLMismatchError?

[07:24:44.0000] <annevk>
Ah, through the name property

[07:25:15.0000] <ccardona-work>
Good morning/afternoon/evening WHATWG crew o/

[07:32:21.0000] <Ms2ger>
I wonder if we should just pull in the WebSocket API spec

[07:32:40.0000] <annevk>
Ms2ger: you mean protocol?

[07:33:35.0000] <Ms2ger>
I can't type

[07:33:37.0000] <Ms2ger>
Yes

[07:34:20.0000] <annevk>
So Chromium does use the URLMismatchError, Gecko just keeps spawning workers

[07:34:25.0000] <annevk>
https://dump.testsuite.org/worker/sharedworker-name.html

[07:34:29.0000] <annevk>
I thought we had tests for this stuff?

[07:34:44.0000] <Ms2ger>
Chrome supports SharedWorker?

[07:34:50.0000] <annevk>
(Mind you, Chromium only does it when the name property is used.)

[07:34:51.0000] <annevk>
Yes

[07:39:28.0000] <annevk>
But Chrome does key on the "scriptURL", not the final URL

[07:39:44.0000] <annevk>
So that location attribute mess has to go

[07:43:41.0000] <annevk>
Ms2ger: what does Servo do?

[07:44:01.0000] <Ms2ger>
We don't have SharedWorkers

[07:44:15.0000] <annevk>
I don't think I can make the PR for this today :-/ But I'll try to write something up tomorrow

[07:44:17.0000] <Ms2ger>
Also no script settings stuff

[07:44:45.0000] <annevk>
I have an alternate solution for the environment settings object stuff

[07:44:55.0000] <Ms2ger>
Sounds good :)

[07:45:19.0000] <annevk>
Just have the environment settings object's API base URL and creation URL return some internal slot from the global

[07:45:38.0000] <Ms2ger>
Hmm

[08:35:21.0000] <wanderview>
/me is trying to remember why we don't want the page URL to update when a navigation is intercepted by a SW.

[08:52:51.0000] <JakeA>
wanderview: because I might respond with caches.match('/static/page-shell-7bfab2c.html')

[08:53:09.0000] <JakeA>
This is what https://wiki-offline.jakearchibald.com/ does

[08:54:07.0000] <JakeA>
https://github.com/jakearchibald/offline-wikipedia/blob/master/public/js/sw/index.js#L82

[08:54:42.0000] <wanderview>
JakeA: you could make that a synthetic response with no Response.url

[08:55:29.0000] <JakeA>
wanderview: I could… but it's a bit messy

[08:56:29.0000] <JakeA>
Either I get shell from the cache, read the text & create a new reponse with it - which loses streaming

[08:56:57.0000] <JakeA>
Or at install time, I fetch the shell, read it as text, and construct a new response with it to cache

[08:57:39.0000] <wanderview>
hmm

[08:58:18.0000] <wanderview>
JakeA: well, I guess thats not the case I was thinking of... I was thinking of allowing opaque responses but making the page URL update

[08:58:24.0000] <wanderview>
instead of rejecting opaque responses

[08:59:10.0000] <JakeA>
wanderview: Allowing opaque responses breaks SOP one way or another

[08:59:53.0000] <JakeA>
If I retain control of the page, I now hear about requests I shouldn't be able to hear about

[09:00:08.0000] <JakeA>
If I don't retain control, that's just a redirect isn't it?

[09:00:10.0000] <wanderview>
JakeA: how is updating the navigation final URL to match the opaque response URL different from a navigation following no-cors cross origin redirects?

[09:00:28.0000] <wanderview>
I guess I'm asking why we can't treat it like a redirect

[09:01:30.0000] <wanderview>
I guess I'm just annoyed because the special cases for navigations keep changing: https://github.com/whatwg/fetch/issues/126

[09:19:34.0000] <JakeA>
wanderview: As in, fetch would generate a redirect to the opaqueResponse.url, then that would go up to the navigate level, change the browser url, then call fetch, which would respond with the opaqueResponse again but unopaqued because the origin is now the same?

[09:20:27.0000] <jtcranmer>
annevk: fwiw, I did finally implement most of UTS #46 in JS

[09:21:11.0000] <Ms2ger>
Now do the same in Rust

[09:21:14.0000] <wanderview>
JakeA: as in the navigation algorithm in http would act as if it had already been redirected Response.url when given an opaque response

[09:22:00.0000] <JakeA>
wanderview: but it would only do this for opaque responses, or all responses?

[09:22:08.0000] <wanderview>
JakeA: ignoring the navigation part here... this is in fact how we plan to implement opaque response tainting in gecko

[09:22:18.0000] <jtcranmer>
Ms2ger: no, because I suspect the people who work on Servo would want support for the bidi and contextual rules and I don't want to touch those with a 20 perch pole

[09:22:54.0000] <wanderview>
JakeA: well, I was originally suggesting for all responses, but I guess it could just do it for opaque responses... if we defined opaque response tainting like this in general

[09:23:46.0000] <annevk>
jtcranmer: I saw, haven't had time to look at it, but cool

[09:26:04.0000] <JakeA>
wanderview: it seems weird for a non-redirect response to become a redirect… what does this improve?

[09:26:36.0000] <jtcranmer>
annevk: it even passes the IDNA test vector suite! well, except for all the tests that require bidi/contextual to be an error

[09:26:57.0000] <jtcranmer>
(and, to be fair, those are the tests where UTS #46 is not following the RFC)

[09:27:59.0000] <wanderview>
JakeA: it lets us keep the simple "opaque responses are ok for no-cors requests" and lets use make navigations "no-cors" requests

[09:29:28.0000] <JakeA>
I haven't gotten my head around the navigation no-cors thing yet

[09:30:01.0000] <wanderview>
I dislike having special extra rules for navigations that developers have to be aware of...

[09:30:28.0000] <wanderview>
we should express the difference in navigations in the primitives we've defined... or come up with better primitives

[09:32:02.0000] <JakeA>
I agree with that, but opaque responses turning into redirects for navigations seems like a specialer rule than "navigation responses cannot be opaque"

[09:34:13.0000] <wanderview>
JakeA: I guess I would find it easier to express if we had a no-cors-navigation RequestMode

[09:35:51.0000] <annevk>
wanderview: can't you infer this from request's destination?

[09:37:44.0000] <wanderview>
annevk: maybe, but how many attributes to we expect developers to check?

[09:38:02.0000] <wanderview>
JakeA: annevk: more realistically, do we expect this to work for navigations?  e.respondWith(fetch(e.request))

[09:38:12.0000] <wanderview>
because its not going to if e.request.url is cross origin

[09:38:22.0000] <JakeA>
That won't happen

[09:38:36.0000] <wanderview>
JakeA: it won't?  why not?

[09:38:54.0000] <JakeA>
If it's a cross origin navigation it'll go to the SW for the scope on the destination origin

[09:39:01.0000] <annevk>
right

[09:40:29.0000] <annevk>
MikeSmith: btw, sorry for not asking earlier, but are you looking for help with the whatwg/html-build PRs?

[09:40:44.0000] <annevk>
MikeSmith: I'm not great with shell, but I can test stuff...

[09:43:26.0000] <wanderview>
ok

[09:44:30.0000] <wanderview>
JakeA: annevk: I guess the problem I am struggling with is RequestMode seems to be acting as our security policy... and but we're polluting that by making it conditional on another attribute

[09:44:50.0000] <jamesr___>
anyone know the history of navigator.productSub ?

[09:45:00.0000] <wanderview>
but I give up

[09:45:07.0000] <jamesr___>
https://html.spec.whatwg.org/multipage/webappapis.html#the-navigator-object lists navigator.product as the constant "Gecko" but doesn't say productsub

[09:45:13.0000] <annevk>
wanderview: you would prefer mode = navigate?

[09:45:54.0000] <annevk>
wanderview: note that we already had a check for navigation requests

[09:46:01.0000] <annevk>
wanderview: for "opaqueredirect"

[09:46:21.0000] <wanderview>
annevk: I know... that seems unnecessary though... why block fetch() from getting opaqueredirect?

[09:46:39.0000] <jamesr___>
in my chrome navigator.productSub is "20030107" and in my firefox it is "20100101"

[09:46:48.0000] <annevk>
wanderview: sigh, I thought we discussed that?

[09:46:57.0000] <annevk>
It would take me a while to remember the arguments again...

[09:47:06.0000] <wanderview>
annevk: we did... i thought you said "better to be conservative for now"

[09:47:17.0000] <annevk>
wanderview: I thought I also pointed out some issues

[09:47:48.0000] <annevk>
wanderview: like the fact that you can't reenter the SW after seeing such a response

[09:48:05.0000] <annevk>
wanderview: which would be inconsistent with other redirects you get from the SW

[09:48:36.0000] <wanderview>
annevk: I would prefer a different RequestMode to express the specialness of navigations

[09:48:39.0000] <annevk>
wanderview: anyway, a mode = navigate could handle both of those

[09:49:10.0000] <annevk>
JakeA: what do you think? ^^

[09:49:43.0000] <wanderview>
I have to go get lunch

[09:49:46.0000] <annevk>
jamesr___: "productSub: Mozilla and Safari only; returns same as buildID in Mozilla, and returns the fixed string "20030107" in Safari" is what a comment says in the source

[09:49:54.0000] <wanderview>
maybe I will be less whiny after eating

[09:50:32.0000] <annevk>
jamesr___: I guess Gecko picked a different time to freeze it

[09:52:26.0000] <annevk>
TabAtkins: UI Events taking over EventTarget et al is back :-(

[09:54:11.0000] <MikeSmith>
annevk: there's no rush on those build PRs. I'm happy just waiting til Domenic has time again

[09:54:45.0000] <MikeSmith>
actually one of them is waiting on me to push changes from the first round of review

[09:55:07.0000] <jamesr___>
annevk: pretty sure chrome inherited that string from webkit

[09:55:14.0000] <annevk>
jamesr___: yeah looks like it

[09:55:24.0000] <jamesr___>
why does this string exist at all? is something required by web compat?

[09:55:29.0000] <jamesr___>
what do edge/IE return?

[09:55:42.0000] <annevk>
jamesr___: I don't know

[09:59:03.0000] <annevk>
MikeSmith: okidoki

[09:59:16.0000] <annevk>
jamesr___: if you find out, you can PR the spec :-)

[10:02:49.0000] <JakeA>
annevk: I'm not against a navigate mode… but I'm not really sure we need it

[10:03:55.0000] <annevk>
JakeA: I guess the rationale is that the security story is somewhat cleaner, but it's rather edge case-y

[10:04:49.0000] <annevk>
JakeA: I do think it makes sense conceptually

[10:05:25.0000] <JakeA>
annevk: happy to go for it then

[10:12:02.0000] <JakeA>
annevk: what does it mean to make a mode:navigate request with redirect:follow?

[10:12:19.0000] <annevk>
JakeA: you wouldn't be able to create them

[10:13:35.0000] <JakeA>
that's fair

[10:14:40.0000] <wanderview>
annevk: another annoyance of mine with opaqueredirect check on navigate...  we allow fetch(url, { redirect: "manual" }), but that will break if its intercepted by a sw that does e.respondWith(fetch(e.request))

[10:15:18.0000] <wanderview>
in that case I would expect the outer fetch() to get the opaqueredirect as well

[10:18:08.0000] <annevk>
wanderview: hmm, I guess we could make that particular check conditional on redirect mode instead

[10:18:25.0000] <annevk>
wanderview: as long as your redirect mode is manual, you'll be able to get an opaqueredirect

[10:18:35.0000] <JakeA>
ohhh I thought that's how it worked

[10:18:38.0000] <wanderview>
annevk: that would be most excellent

[10:18:52.0000] <annevk>
wanderview: file an issue?

[10:18:55.0000] <wanderview>
sure

[10:22:55.0000] <wanderview>
https://github.com/whatwg/fetch/issues/127

[10:32:56.0000] <Domenic>
Hmm the images URLs change hasn't made it to the spec

[10:33:44.0000] <annevk>
Domenic: did you update the server copy of wattsi?

[10:33:53.0000] <Domenic>
annevk: it should auto-update

[10:34:19.0000] <annevk>
Domenic: ah, maybe it's broken just like my local copy because the GitHub thing is no longer a fork?

[10:34:34.0000] <Domenic>
annevk: that would be surprising... but maybe

[10:34:54.0000] <annevk>
Domenic: I couldn't update whatwg/wattsi earlier today; kept complaining

[10:35:05.0000] <annevk>
Domenic: ended up removing it and just fetching it anew

[10:35:06.0000] <Domenic>
I haven't had any problems, hmm

[10:35:25.0000] <annevk>
Domenic: maybe it's the GitHub client that was the problem...

[10:35:49.0000] <Domenic>
At least the whatwg/html changes are still making it in, so the build is not breaking...

[10:35:56.0000] <Domenic>
I really should set up some sort of email for if the build breaks

[10:36:20.0000] <Domenic>
Of course then I start wondering about setting up a whole proper CI server thingy

[10:36:48.0000] <annevk>
Oh the server doesn't use git

[10:36:54.0000] <annevk>
It just fetches a zip

[10:37:01.0000] <Domenic>
it probably should though, the zip thing is a bit convoluted

[11:16:31.0000] <beverloo>
annevk, sicking, do notifications in Firefox close when you click on them?

[11:16:52.0000] <sicking>
don't know

[11:16:57.0000] <sicking>
sorry

[11:17:06.0000] <sicking>
not been involved with the desktop side

[11:17:33.0000] <beverloo>
ok, they seem to on Linux, but I need to test whether the onclose event fires as well

[11:43:21.0000] <TabAtkins>
annevk: Investigating

[12:05:42.0000] <annevk>
beverloo: not on OS X

[12:05:57.0000] <annevk>
beverloo: close fires when you dismiss them from the notification center

[12:06:59.0000] <annevk>
beverloo: also, seems to require two clicks before click fires

[12:15:45.0000] <zcorpan>
annevk: i don't understand your concern in https://www.w3.org/Bugs/Public/show_bug.cgi?id=26024

[12:33:27.0000] <annevk>
zcorpan: say e.g., you use <img src=https://www.google.com/> on example.com; a drag & drop should not reveal what google.com redirected too, that violates SOP

[12:34:22.0000] <zcorpan>
annevk: ah ok. currentSrc only gives the resolved URL before redirects

[12:34:59.0000] <annevk>
zcorpan: if it's just one of the URLs from the markup that's fine

[12:35:09.0000] <zcorpan>
yeah

[12:45:36.0000] <Krinkle>
Ah that reminds me of an attack from a few years ago involving flash, invisible iframes and a simple "slide to unlock" kind of game drawn on top.

[12:45:41.0000] <Krinkle>
Users weren't aware of what they were doing.

[12:46:23.0000] <Krinkle>
I forget what it was but it was something but hotmail redirecting to a session subdomain.

[12:46:26.0000] <Krinkle>
if logged in


2015-09-18
[20:07:51.0000] <mnot>
annevk: you about?

[20:33:45.0000] <JonathanNeal>
Could the CSS Color Module be used to invert a color? My usecase is styling `::selection`and wanting the color to be the inverse of the background.

[20:40:28.0000] <caitp>
https://drafts.csswg.org/css-color/ has some comments about that, so it sounds like probably not yet

[20:40:51.0000] <caitp>
i mean, in current implementations, no, maybe some day

[21:41:09.0000] <caitp>
annevk: I was going to say, it would be really handy if the full markup was generated from markdown or something, so that it's easier to read the blame

[21:41:34.0000] <annevk>
caitp: HTML is hard to read?

[21:41:54.0000] <caitp>
yeah, when the bulk of it is not the actual text content

[21:42:09.0000] <annevk>
I guess

[21:42:34.0000] <annevk>
I don't really have the bandwidth to convert specs to markdown though while retaining all the same features

[21:43:27.0000] <caitp>
yeah, but somewhere out there there's a college kid learning python or node or something that needs something to work on

[22:06:08.0000] <annevk>
caitp: oh, so the whitespace is the problem for these "bearer" tokens? Not e.g., 0x02 bytes?

[22:07:22.0000] <caitp>
well the problem is that they're programmatically building the header, and OAUTH wants it to be "Bearer<whitespace>SomeThing", I guess

[22:07:40.0000] <caitp>
and they historically haven't had to make sure the value is non-empty

[22:07:44.0000] <caitp>
so, they don't

[23:09:32.0000] <annevk>
if we had to preserve whitespace there that actually violates HTTP semantics

[23:09:41.0000] <annevk>
that would be something

[01:23:09.0000] <annevk>
I'm having a hard time understanding why SharedWorker has both URL and name, when they're required to match anyway

[01:25:23.0000] <zcorpan>
annevk: isn't it to be able to start a separate instance of a shared worker?

[01:27:28.0000] <annevk>
zcorpan: ah okay

[01:28:20.0000] <annevk>
zcorpan: do you know why empty string name and non-empty string are handled differently in the constructor?

[01:28:44.0000] <annevk>
zcorpan: I don't understand why non-empty string doesn't check the URL straight away too and instead throws an exception later on for it...

[01:31:53.0000] <annevk>
I guess name has to be sole key

[01:32:01.0000] <annevk>
And when name is empty, the constructor URL is the key

[01:33:50.0000] <zcorpan>
annevk: step 6 makes a difference there, but i don't know if it is intentional to not throw in that mode

[01:35:26.0000] <annevk>
zcorpan: afaict Firefox just keys on both constructor url and name

[01:35:31.0000] <annevk>
zcorpan: and therefore never reaches 7.1

[01:36:31.0000] <annevk>
zcorpan: I guess it depends on whether you want names to be unique or not, but it seems empty string is already not unique

[01:36:31.0000] <zcorpan>
ok. i don't know why the spec is as it is

[01:36:45.0000] <annevk>
Chrome does do this per spec though

[01:50:33.0000] <zcorpan>
annevk: certainly for the purpose to just be able to start a separate instance of a shared worker, there is no need for URLMismatchError

[01:51:12.0000] <annevk>
The only reason I can imagine is that you want non-empty string names to be unique

[01:51:45.0000] <annevk>
I don't think that's particularly great design

[01:55:31.0000] <annevk>
zcorpan: any idea who from Chromium we can convince that this should be changed?

[02:32:50.0000] <zcorpan>
annevk: sof implemented workers in presto. otherwise dunno; maybe someone from https://code.google.com/p/chromium/issues/detail?id=327256

[02:59:29.0000] <Ms2ger>
annevk, so you can still detect whether a cross-origin file is well-formed JS by calling importScripts? Does <script> already expose that?

[03:03:21.0000] <annevk>
Ms2ger: hmm, I think <script> calls report the exception in that case which ends up on the Window object

[03:04:47.0000] <Ms2ger>
Seems plausible

[03:04:51.0000] <annevk>
Ms2ger: actually, I'm not sure how importScripts() ever ends up there given that it too uses "create a script" which already reports the errors

[03:05:09.0000] <annevk>
Ms2ger: I'm mainly concerned about the "ok status" leak, but that was already present...

[03:08:03.0000] <annevk>
Ms2ger: ah, it gets there because it also starts running the script

[03:12:17.0000] <annevk>
Added some thoughts to the PR on potential further improvements

[04:01:14.0000] <annevk>
wanderview: so you asked at some point whether fragments need to be preserved, it seems workers preserve them

[04:05:36.0000] <annevk>
So much churn :-(

[04:37:31.0000] <JonathanNeal>
TabAtkins: a usecase for inverting a color is styling `::selection`and wanting the text color to be the inverse of the background. https://drafts.csswg.org/css-color/

[04:41:37.0000] <frewsxcv>
<font size=2>hello</font>

[04:41:49.0000] <frewsxcv>
What should the computed font size for that be?

[04:45:54.0000] <zcorpan>
sigh, free pascal installer refuses to install. it says i need xcode and command line tools, which i have installed

[04:49:20.0000] <zcorpan>
or hmm, maybe command line tools thing failed

[05:05:40.0000] <jgraham>
zcorpan: You might need to accept the license agreement

[05:08:15.0000] <zcorpan>
jgraham: i managed to download and install the command line tools from developer.apple.com

[05:08:53.0000] <jgraham>
OK

[05:09:20.0000] <jgraham>
The usual problem with Xcode is that you need to actually start it and accept a license agreement before the command line parts work

[05:14:36.0000] <zcorpan>
ok. i had started it so it was some other problem :-)

[05:16:14.0000] <Ms2ger>
frewsxcv, there's something in HTML for that

[05:40:06.0000] <wanderview>
annevk: you're saying you want Request to preserve fragments?  JakeA does this mean Cache API needs to preserve request fragments?

[05:47:35.0000] <frewsxcv>
Ms2ger: right. The html spec specifies which absolute String they map to, like xx-large. Do you know where it's specified bow that String gets turned into a scale ratio?

[05:49:51.0000] <Ms2ger>
There's a table at https://drafts.csswg.org/css-fonts/#font-size-prop

[05:51:33.0000] <frewsxcv>
So I saw that table. Though it appears blink and Gecko don't follow it. I guess I'll just look at their source

[05:55:18.0000] <frewsxcv>
for example, <font size=2> with gecko results in font-size == 13px. whereas 8/9 * 16 = 14.2222222222222

[05:56:00.0000] <frewsxcv>
i also find it strange how both gecko and blink have nice whole numbers for pixels. maybe pixels aren't allowed to be decimal and they round?

[05:56:42.0000] <Ms2ger>
frewsxcv, they have tables for small base font sizes

[05:57:07.0000] <frewsxcv>
they == blink+gecko ?

[05:58:07.0000] <Ms2ger>
I'm pretty sure Gecko does, and probably Blink too

[05:58:46.0000] <frewsxcv>
does that go against the spec?

[05:58:59.0000] <JakeA>
wanderview: annevk: hm, I'd be surprised to see them in the request url… where is it they surface in works?

[05:59:03.0000] <JakeA>
workers*

[05:59:07.0000] <Ms2ger>
Yeah

[06:53:34.0000] <annevk>
JakeA: self.location

[06:53:56.0000] <annevk>
wanderview: guess so

[06:55:57.0000] <wanderview>
annevk: does this have to effect the script visible Request object?  seems self.location could pull from the inner request url

[06:55:59.0000] <annevk>
frewsxcv: nah, the spec just calls it guidelines

[06:56:38.0000] <annevk>
wanderview: yeah we could Request alone still, seems a tad weird perhaps since it has an effect on workers (of sorts)

[06:57:13.0000] <wanderview>
annevk: I think workers are weird for letting fragments be a thing in their script location

[06:59:54.0000] <frewsxcv>
annevk: so should there not be any tests in web-platform-tests for this since it's pretty much a guideline?

[07:02:44.0000] <Ms2ger>
frewsxcv, if browsers agree, I guess we should just spec and test it

[07:02:47.0000] <Ms2ger>
("just")

[07:03:13.0000] <frewsxcv>
what do you mean by 'spec it'?

[07:03:18.0000] <frewsxcv>
add it to the spec?

[07:04:06.0000] <Ms2ger>
Yes

[07:44:58.0000] <annevk>
wanderview: I don't disagree, but not sure it's worth fixing it

[07:45:10.0000] <annevk>
wanderview: and I guess you could use it for something

[07:45:25.0000] <annevk>
But having both fragments and names to play with as keying mechanisms seems a bit much

[07:48:07.0000] <wanderview>
annevk: JakeA: it would really be nice to have a convenient way to construct a new Request from an old Request and an overriding url

[07:48:46.0000] <annevk>
wanderview: hmm

[07:51:17.0000] <wanderview>
maybe thats not my problem

[07:56:14.0000] <annevk>
wanderview: I guess we could offer that at some point

[07:56:46.0000] <wanderview>
annevk: I've just seen a couple pieces of code that need to do that and get it wrong

[07:57:11.0000] <wanderview>
forget to propagate something like body or headers or a new field that was added to Request

[07:57:37.0000] <annevk>
wanderview: I see, file an issue?

[07:57:44.0000] <wanderview>
ok

[08:00:36.0000] <wanderview>
annevk: https://github.com/whatwg/fetch/issues/129

[08:04:35.0000] <JakeA>
wanderview: could it be new Request(url, oldRequest)?

[08:05:00.0000] <wanderview>
JakeA: that would work for me

[08:05:25.0000] <wanderview>
its unclear to me if some contents of the Request should not be propagated... type, destination, unsafe-request flag, etc

[08:05:26.0000] <JakeA>
Does that not already work?

[08:05:34.0000] <JakeA>
ahh ok

[08:05:46.0000] <wanderview>
JakeA: the second arg of Request constructor is RequestInit... a dictionary

[08:06:05.0000] <wanderview>
JakeA: which works for most thing... but not propagating the body

[08:06:17.0000] <JakeA>
Ahh fair enough

[08:06:26.0000] <wanderview>
JakeA: although maybe that would work after streams land?

[08:07:02.0000] <JakeA>
wanderview: Once .body is fully known, it could be made to work I guess

[08:09:34.0000] <wanderview>
I don't know why I forgot Request could be passed as the dictionary

[08:19:34.0000] <wanderview>
JakeA: I guess maybe this code wants to override the url and like one or two other fields....

[08:20:37.0000] <JakeA>
wanderview: I guess you want something to turn a request into a mutable requestInit type of thing

[08:20:48.0000] <wanderview>
yea

[08:21:07.0000] <wanderview>
I guess script can do that anyway

[11:03:19.0000] <ccardona-work>
Good morning/afternoon/evening WHATWG crew o/

[12:33:18.0000] <Krinkle>
JakeA: Do you reckon the outcome of "Aborting a fetch" / cancellable promise/task etc. will be one that is polyfillable? I can't wait to be able to use it in all browsers, today. This comes up like every 48 hours in my job. And gets worked around in horrendous hurtful and counter-intuitive ways.

[12:34:22.0000] <Domenic>
Krinkle: if you are willing to re-build fetch + promises from scratch then yes.

[12:34:32.0000] <Domenic>
(both are doable, on top of XHR and nothing, respectively.)

[12:34:42.0000] <Krinkle>
yeah.

[12:35:25.0000] <Krinkle>
I could just pick one of the ideas there and have "something", but I do have the discipline to wait a bit longer so that I'm not betting on the approach that didn't make it and have to re-educate everyone when we change things again.

[12:35:59.0000] <Krinkle>
the while .then() loses .abort() with ajax is the main driver here.

[12:36:03.0000] <Krinkle>
whole*

[12:36:31.0000] <Domenic>
What "whole .then() loses .abort() with ajax"?

[12:36:32.0000] <Krinkle>
Global singletons keeping track of of XHRs etc. it's just unmaintainable and prone to error.

[12:37:27.0000] <Krinkle>
Domenic: A common pattern is to abort requests based on user input. Either from debouncing or otherwise. But further in processing, every then() later, you lose the original .abort from the initial jQuery promise that had .abort tacked on.

[12:37:59.0000] <Domenic>
I thought we were talking about fetch, not jQuery.

[12:38:08.0000] <Krinkle>
Yes

[12:38:21.0000] <Krinkle>
It's all part of an endless pyramid of problems and concerns

[12:38:45.0000] <Krinkle>
whatever pattern we settle on here, will be one we can re-use elsewhere as a logical unit of how to deal with this

[12:38:54.0000] <Krinkle>
API wise, not implementation wise

[12:39:21.0000] <Krinkle>
We can apply it to our library that deals with internal API requests (which uses ajax() internally)

[12:41:13.0000] <Krinkle>
e.g. mw.Api#getCategories -> mw.Api#getPageInfo -> jQuery.ajax; Then consumer UI code calls getCategories() and needs a way to .abort / cancel / ignore / ensure it won't ever callback.

[12:42:47.0000] <Domenic>
How would you feel about an approach where you pass a cancelation toekn to getCategories, which passes it to getPageInfo, which passes it to, well, fetch, not jQuery.ajax.

[12:44:57.0000] <Krinkle>
I can't say I'm very keen on such interface. It feels unnecessarily formal and overhead.

[12:45:38.0000] <Krinkle>
But if that's the way it will be, I'm okay with that. I'll become part of how we use fetch() and a familiar behaviour and pattern we'll encounter anyway, so might as well use that in our library.

[12:46:03.0000] <Krinkle>
At this point I've lost any and all preferences or pleasantry, I'm too eager to just have an answer.

[12:46:40.0000] <Krinkle>
In another month or so we'll probably just pick an approach and abstract it a bit so we can easily switch to fetch() internally.

[12:50:52.0000] <Krinkle>
The chain-aware ness seems achievable

[12:51:03.0000] <Krinkle>
Though I agree with JakeA that this only works when strictly chaining.

[12:51:31.0000] <Krinkle>
When passing on a promise received by closure instead of then(), there is no longer that explicit link, not until the code executes.

[12:51:53.0000] <Krinkle>
RE: There's a bunch of good ideas there but I do have the discipline to hold off a little longer to avoid having to enter a paradigm shift when the eventual apparoach

[12:51:59.0000] <Krinkle>
* RE: https://github.com/whatwg/fetch/issues/27#issuecomment-92929061

[12:58:10.0000] <annevk>
Krinkle: I'm mostly being patient too, waiting for Domenic and JakeA to come up with something

[12:58:34.0000] <Domenic>
We're having a mini cancelable promises summit next Monday before TC39

[12:58:35.0000] <annevk>
Krinkle: doesn't seem worth it to add something to the specification now since whatever we add we'll have to live with for a long time

[12:58:52.0000] <Domenic>
The biggest issue in my mind right now is that the ref-counting CancelablePromise subclass approach doesn't work with async functions

[12:59:14.0000] <Domenic>
So we want to noodle on that for a bit

[12:59:43.0000] <Krinkle>
Domenic: Hm.. because await is an implicit then?

[12:59:58.0000] <annevk>
So, https://github.com/w3c/charter-html/issues/112

[13:00:02.0000] <annevk>
Anyone opinions?

[13:00:25.0000] <Domenic>
Krinkle: because async functions always return Promises, not CancelablePromises.

[13:00:37.0000] <annevk>
I'm sort of at the point where I would just like this to stop, but it seems that's unrealistic at least for a while longer...

[13:00:41.0000] <Domenic>
annevk: My opinion is they should stop copying their specs.

[13:00:53.0000] <Domenic>
s/their/the

[13:01:18.0000] <Domenic>
But dbaron basically blew that out of the water by asking for text saying "we plan to copy."

[13:01:48.0000] <annevk>
Yeah... I normally agree with dbaron but I'm torn on this one

[13:01:55.0000] <Domenic>
Whatever, they don't have enough editors to copy things anyway. I plan to ignore it.

[13:02:14.0000] <Domenic>
bbiab meeting

[13:02:34.0000] <annevk>
If they had done a decent job of copying in the past I would be more sympathetic, but most things just end up being a disaster

[13:02:59.0000] <annevk>
In fact, pretty sure that's all

[13:04:00.0000] <dbaron>
you're welcome to suggest alternatives

[13:04:16.0000] <dbaron>
I tend to think that asking the W3C to not have a spec for HTML probably won't go over very well, though.

[13:06:19.0000] <Domenic>
This is interesting https://stackoverflow.com/questions/32656594/domcontentloaded-blocks-page-loading

[13:11:48.0000] <annevk>
dbaron: well, it's true that it hasn't worked so far

[13:12:21.0000] <dbaron>
I meant "won't be well received" when I said "won't go over very well"

[13:13:47.0000] <MikeSmith>
the W3C organizationally cannot force the WG to publish a spec for HTML or anything else. Especially if the members of the WG don't support doing it

[13:14:38.0000] <MikeSmith>
the fact that the charter puts a spec in the scope of the WG does not mean that the group is obligated to actually publish that spec

[13:14:39.0000] <annevk>
dbaron: I guess I'm not really sure what to say, I've made many suggestions to Jeff over the years, but it usually comes down to no compromise from their side. I think I'm at the same point Hixie and Domenic are at, that caring is probably not really worth the effort.

[13:15:09.0000] <annevk>
Domenic: that follows pretty straightforwardly from the event loop section of the spec

[13:15:27.0000] <Domenic>
annevk: well, Chrome requiring two rAFs is at least strange.

[13:16:13.0000] <Domenic>
I guess update the rendering does happen after run the task though

[13:16:52.0000] <annevk>
Domenic: oh, I missed that

[13:18:16.0000] <Domenic>
Also, am I reading this right? The event loop section implies update the rendering more often than 60 times per second?

[13:18:19.0000] <MikeSmith>
annevk: "straightforwardly" there reminds of the job about the two mathematicians who argue about some point for hours and in the end one of them changes his position and says oh yeah it's "obvious" that what that other has been asserting is in fact right

[13:18:42.0000] <MikeSmith>
s/job/joke/

[13:18:58.0000] <annevk>
MikeSmith: well, isn't it? :-P

[13:19:57.0000] <MikeSmith>
yes! 😆  (says the mathematician in me after 3 hours of reading)

[13:20:32.0000] <annevk>
Domenic: it allows for it, see 8.3 for why it's not required

[13:20:58.0000] <annevk>
Domenic: and that makes sense, e.g., I believe VR would like 120 Hz if not more

[13:21:52.0000] <Domenic>
Ah, missed 8.3

[14:40:37.0000] <jamesr>
many displays are not 60Hz

[14:40:40.0000] <jamesr>
some are slower, some are faster

[14:41:36.0000] <jamesr>
when a browser actually renders stuff is pretty much 100% unspecified

[15:12:07.0000] <MikeSmith>
in GitHub lingo, what is the term for the repo from which a network of other repos have been forked?

[15:12:11.0000] <MikeSmith>
Source repo?

[15:12:15.0000] <MikeSmith>
Base?

[15:13:53.0000] <MikeSmith>
Upstream.. Original

[15:14:03.0000] <MikeSmith>
I guess I will just use "Origin"

[15:22:49.0000] <nox>
gsnedders: Did you take a look at https://github.com/html5lib/html5lib-tests/pull/69?

[16:56:43.0000] <Krinkle>
Hm.. DOMContentLoaded blocking paint is kind of neat in my opinion. It gives clients a chance to modify things without FOUC-y behaviour (e.g. hide elements based on cookies). However I assume this is only the case on small and/or unbuffered pages. Because iirc Chrome can (should) do first paint earlier if it received enough html content.


2015-09-19
[17:00:13.0000] <jamesr>
yes, you can't depend on DOMContentLoaded necessarily blocking paint

[17:02:39.0000] <jamesr>
d'oh

[19:18:58.0000] <MikeSmith>
Domenic: dunno how you came across https://stackoverflow.com/questions/32656594/domcontentloaded-blocks-page-loading (I had earlier today as well, just from browsing through new questions) but I read through some of his other answers and some others of them are also pretty clever

[20:35:32.0000] <JonathanNeal>
TabAtkins: thinking alot about your comments regarding write-svg and your suggestion to create elements with further at-rules, like @rect. That seems like too many custom at-rules and <font-face> / @font-face seems particularly troubling. In the odd event you’re around, I was kicking around some other solutions.

[20:37:10.0000] <JonathanNeal>
One would be to treat inner @svg at-rules as selectors for the element, like @svg id_of_svg { @svg rect#thing {} } // generates something like <svg><rect id=“thing”/></svg>

[21:08:47.0000] <TabAtkins>
JonathanNeal: "Number of at-rules" isn't significant.

[21:09:26.0000] <TabAtkins>
<font-face> can be safely ignored; we're dropping it from SVG in the first place.

[21:18:30.0000] <JonathanNeal>
So it's okay to have a few dozen at rules?

[21:19:38.0000] <TabAtkins>
They're all scoped to only be valid within @svg.

[21:19:40.0000] <TabAtkins>
So sure.

[00:05:55.0000] <JonathanNeal>
Should it allow any node or limit itself to a list of valid SVG nodes? @svg <name> { @element-Name { ... } }


2015-09-20
[20:56:45.0000] <JonathanNeal>
I’m trying to write about css positioning, and I am missing the right word here when talking about top right bottom and left. Those properties describe ... position … offsets, margins, coordinates?

[20:57:03.0000] <JonathanNeal>
edges?

[13:20:25.0000] <frewsxcv>
did there used to be a 'creator' WebIDL attribute?

[13:31:56.0000] <Ms2ger>
Yeah

[13:32:02.0000] <Ms2ger>
Merged into `setter` now


2015-09-21
[22:54:32.0000] <annevk>
https://twitter.com/arturotena/status/645708214458159104 heh

[22:55:22.0000] <annevk>
jamesr: well, it's specified that the browser renders between tasks and not during them (as Opera used to do and would trip folks up)

[01:35:28.0000] <Huvet>
Hi! I have some horrible HTML generated by Outlook that I want to parse with html5lib... it seems it's filled with <u/> tags all over. But since html5lib parses that as a regular <u> the whole document gets underlined. Is there a way in html5lib to allow more tags to be "self-closing"?

[01:36:07.0000] <annevk>
Huvet: you'd have to modify html5lib

[01:36:21.0000] <annevk>
Huvet: might be easier to search and replace <u/> with <u></u> first

[01:36:57.0000] <annevk>
Huvet: or remove <u/> before parsing or u elements after parsing

[01:38:48.0000] <Huvet>
damnit, wish there was a way to "expand" them beforehand... but doing that with a regex or string replace leads to insanity, or so I've read on Stackoverflow

[01:39:44.0000] <Huvet>
thanks!

[01:40:13.0000] <annevk>
Huvet: yeah, that's probably not a good idea unless the input is highly predictable

[01:40:24.0000] <annevk>
Huvet: just iterating through the tree afterwards is likely saner

[01:41:13.0000] <Huvet>
but afterwards means it's already too late... there can be correct <u> tags in there too, so I don't want to replace all of them

[01:41:41.0000] <Huvet>
so since html5lib borks them I need to do it before everything else

[01:42:54.0000] <Huvet>
what if I monkeypatch html5lib.constants.voidElements?

[01:45:26.0000] <Ms2ger>
Voids your warranty :)

[01:48:05.0000] <Huvet>
Yeah, I'll just parse HTML with a regex beforehand instead :)

[01:49:52.0000] <jgraham>
I hate to be the one asking stupid questions, but I assume it doesn't parse with an XML parser?

[01:52:22.0000] <Huvet>
It's random HTML from the internet, so I don't trust a xml parsers to touch it at all

[01:52:23.0000] <annevk>
Huvet: if you change voidElements you'll mess up the correct <u> elements too

[01:54:28.0000] <Huvet>
yeah, I'll keep my warranty and do it with regexps

[01:55:34.0000] <annevk>
Hah, not sure if I have this pile of regexps applied and then run the HTML parser and it doesn't really work will get you much help :-P

[02:01:26.0000] <Huvet>
"they told me to parse with regexp in #whatwg" <- great T-shirt print

[02:15:56.0000] <zcorpan>
modifying the html parser isn't gonna make you saner than running a regex :-)

[02:58:10.0000] <MikeSmith>
> "they told me to parse with regexp in #whatwg" 🏆 😆

[05:58:22.0000] <MikeSmith>
nginx finally has some real competition in terms for performance https://h2o.examp1e.net/ https://github.com/h2o/h2o

[05:59:10.0000] <MikeSmith>
actually it doesn't seem like much of competition ーh2o is just way faster

[06:00:57.0000] <MikeSmith>
also there's nghttp2 https://github.com/tatsuhiro-t/nghttp2 which is an HTTP/2 library that curl now uses

[06:05:21.0000] <jgraham>
If only it was rust ;)

[06:15:15.0000] <zcorpan>
ok i'm now having trouble installing this perl XML::parser thing

[06:15:31.0000] <nox>
Just use MARPA.

[06:15:31.0000] <zcorpan>
"Warning: Cannot install XML::parser, don't know what it is."

[06:15:34.0000] <nox>
/me runs away.

[06:15:47.0000] <MikeSmith>
jgraham: yeah

[06:15:49.0000] <jgraham>
zcorpan: Dare I ask why?

[06:15:59.0000] <zcorpan>
jgraham: https://github.com/whatwg/html-build

[06:16:05.0000] <nox>
jgraham: Talking about Rust,

[06:16:14.0000] <jgraham>
zcorpan: Ugh

[06:16:18.0000] <nox>
jgraham: it's been twice that html5lib-tests got new tests,

[06:16:38.0000] <nox>
jgraham: and both times, the differences between the tests and h5e were coming from errors in the former. :)

[06:17:14.0000] <MikeSmith>
jgraham: there's a perl script used in the HTML spec build that parses a Unicode-related XML file that is a dependency for the cooked spec

[06:17:21.0000] <jgraham>
nox: Are you volunteering to be a test reviewer?

[06:17:24.0000] <jgraham>
:)

[06:17:35.0000] <MikeSmith>
sounds like nox is

[06:17:56.0000] <nox>
jgraham: I kinda am, but some slipped through.

[06:18:26.0000] <MikeSmith>
in the case of the ruby tests that might have been at least partially my fault

[06:18:27.0000] <nox>
jgraham: There were some weird tests with the latest Blink bump. You merged one of the fixes, and I made a PR for the other one, feel free to review it BTW. :D

[06:19:20.0000] <jgraham>
nox: I think the problem with tests from Blink is that those tests are often wrong

[06:19:35.0000] <nox>
jgraham: Yes…

[06:19:42.0000] <jgraham>
Because they write tests according to what they would like the spec to be rather than what it actually is, or something

[06:19:44.0000] <nox>
jgraham: Should run h5e against them before merges. =)

[06:21:51.0000] <zcorpan>
ah now it seems it's working. should be XML::Parser, not XML::parser

[07:02:22.0000] <MikeSmith>
jgraham: https://github.com/tatsuhiro-t/nghttp2 has Python bindings btw

[07:02:52.0000] <MikeSmith>
sadly no Pascal bindings yet for us Pascal fans, but we can hope

[07:02:55.0000] <zcorpan>
MikeSmith: html-build says "Local wattsi is not present; trying the build server..." although i have (tried to) build wattsi

[07:03:13.0000] <MikeSmith>
zcorpan: you need to put wattsi in your PATH

[07:04:01.0000] <MikeSmith>
I have the build script just doing a simple "hash wattsi" check for it

[07:04:20.0000] <zcorpan>
MikeSmith: ok, bin/wattsi in the wattsi clone?

[07:04:41.0000] <MikeSmith>
yeah, if that's where you have it

[07:04:58.0000] <MikeSmith>
then that ./bin dir needs to be in your path

[07:05:26.0000] <MikeSmith>
the build script doesn't do any magic checking for it elsewhere

[07:07:41.0000] <MikeSmith>
@tatsuhiro_t, the developer of nghttp2, also has the coolest avatar imaginable https://github.com/tatsuhiro-t

[07:08:48.0000] <zcorpan>
MikeSmith: works now, thx

[07:08:54.0000] <MikeSmith>
super

[07:09:14.0000] <MikeSmith>
you will be able to build fast now

[07:09:43.0000] <MikeSmith>
./build.sh --no-update should complete in 15 seconds or less

[07:10:24.0000] <MikeSmith>
which is pretty impressive given the size of the HTML document it's processing and everything it's doing

[07:13:24.0000] <MikeSmith>
https://nghttp2.org/httpbin is fun (nghttp2 testing page)

[07:23:28.0000] <zcorpan>
woot, managed to take the right steps to merge my PR

[07:23:36.0000] <MikeSmith>
nice

[07:24:05.0000] <MikeSmith>
/me looketh upon it with admiration

[07:25:41.0000] <MikeSmith>
zcorpan: please always go back to the PR and delete the review branch

[07:25:55.0000] <MikeSmith>
otherwise the branch bear will bite you

[07:26:20.0000] <zcorpan>
k

[08:04:56.0000] <zcorpan>
philipj: MikeSmith: re https://github.com/whatwg/html/commit/0a5aea3590336e260ffd8d35de84425360095520 maybe we should make everything give both explicitly, i suppose that makes the spec easier to understand?

[08:05:59.0000] <philipj>
zcorpan: doing that would indeed lead to less confusion of the sort that led to this change and revert

[08:07:37.0000] <zcorpan>
filed an issue

[10:04:37.0000] <annevk_>
So am I just getting a cached version or is something up with building the specification again?

[10:04:45.0000] <annevk>
Still shows September 17 here

[10:04:47.0000] <annevk>
Domenic?

[10:04:48.0000] <botie>
Domenic is, like, awake

[10:04:53.0000] <annevk>
Excellent

[10:05:36.0000] <Domenic>
Sounds like a potential build issue, will investigate

[10:08:58.0000] <Domenic>
problem identified... should be fixed, will make GitHub re-ping the server to test

[10:11:32.0000] <annevk>
Domenic: what's the email address of the new person editing ECMAScript?

[10:12:10.0000] <Domenic>
annevk: that's bterlson, brian.terlson⊙gc

[10:12:48.0000] <Ms2ger>
A new person editing ECMAScript?

[10:13:03.0000] <annevk>
Domenic: ta

[10:13:12.0000] <Ms2ger>
Do they know HTML?

[10:13:12.0000] <bterlson>
hello

[10:13:18.0000] <bterlson>
what is HTML?

[10:13:36.0000] <bterlson>
XHTML ftw

[10:13:40.0000] <annevk>
bterlson: does your @microsoft.com account still work?

[10:13:40.0000] <bterlson>
I know the doctype by heart

[10:13:49.0000] <bterlson>
I sure hope so!

[10:13:56.0000] <annevk>
That's the one autocomplete gave me

[10:14:09.0000] <bterlson>
should work

[10:14:46.0000] <bterlson>
brian.terlson⊙mc is probably better for all ecmascript-related things

[10:15:34.0000] <annevk>
ta

[10:17:00.0000] <Domenic>
annevk: spec fixed, shows 21 September now

[10:38:29.0000] <annevk>
\o/

[10:45:01.0000] <annevk>
I guess I should do some studying tomorrow: https://twitter.com/BrendanEich/status/646013302548525056

[10:53:32.0000] <annevk>
Woohoo, 6/11 worker things fixed

[10:55:42.0000] <Domenic>
annevk: bterlson and I are having a cancelable promises summit today

[10:56:13.0000] <bterlson>
Domenic: You going to Tilde?

[11:04:23.0000] <annevk>
No tweet for my workers commit...

[11:04:38.0000] <annevk>
But the hook says all is dandy

[11:04:57.0000] <annevk>
Oh well, good enough for today

[12:34:16.0000] <nox>
annevk: Some studying?

[12:39:49.0000] <MikeSmith>
zcorpan: yeah, removing a level of indirection that implementors reading the spec need to deal with there would be a plus

[12:43:07.0000] <TabAtkins>
JonathanNeal: Re top/etc - those properties specify offsets from the containing block.

[12:43:15.0000] <TabAtkins>
From the relevant containing block edge, that is.

[12:46:03.0000] <JonathanNeal>
Thanks TabAtkins !

[14:10:33.0000] <slightlyoff>
zomg, how did the Storage API fuck up provisional grants?

[14:11:01.0000] <slightlyoff>
and "estimate" vs. "persistantEstimate"...WTF?

[14:11:07.0000] <slightlyoff>
nothing about this make sense

[14:12:08.0000] <slightlyoff>
annevk: we need an API that lets us know if durable storage WOULD be granted if it was requested, without needing to run the prompt

[14:28:19.0000] <slightlyoff>
I guess we can extend the Permissions API to handle this case

[14:28:22.0000] <slightlyoff>
will talk to Mounir

[14:29:28.0000] <slightlyoff>
actually, PersistentStoragePermission needs to be extended

[16:02:00.0000] <slightlyoff>
the specific case here is that we might want to auto-grant this and developers need to know if something *would* be granted if they asked

[16:02:06.0000] <slightlyoff>
I'll file a bug


2015-09-22
[18:58:02.0000] <estellevw>
I was trying to test out invalid values for the `transition-property` property and it doesn’t seem to be following the spec in FF and Chrome, though i may be interpreting the spec incorrectly.

[18:58:15.0000] <estellevw>
http://codepen.io/estelle/pen/avZKEo

[18:58:41.0000] <estellevw>
“none, inherit, and initial are not permitted as items within a list of more that one identifier; any list that uses them is syntactically invalid."

[18:59:10.0000] <estellevw>
also, oddly, FF is animating the border-style property, but is doing so incorrectly, if that is at all possible

[19:08:06.0000] <TabAtkins>
estellevw: Correct, our handling of "none" is wrong - we should be rejecting that declaration.

[19:08:21.0000] <estellevw>
should i file a bug?

[19:08:33.0000] <estellevw>
and, any clue what’s going on with FF animating the border-style

[19:08:46.0000] <estellevw>
and ending up with the pre-value instead of the post value

[19:08:51.0000] <estellevw>
thanks btw

[19:14:47.0000] <MikeSmith>
/me waves to estellevw 

[19:16:16.0000] <estellevw>
hi MikeSmith

[19:16:30.0000] <MikeSmith>
hey there

[19:17:19.0000] <MikeSmith>
estellevw: your participation in https://discourse.wicg.io/ would be very welcome (in case you've not already been there and I've not noticed)

[19:17:45.0000] <MikeSmith>
also, your help in the WICG as your time permits

[19:18:07.0000] <estellevw>
never heard of it. thanks.

[19:18:21.0000] <MikeSmith>
yeah it just got rolling recently

[19:18:30.0000] <estellevw>
cool

[19:19:07.0000] <estellevw>
aso, i am looking for a job if anyone knows a good fit that is hiring (or not hiring, but still wants me)

[19:24:14.0000] <estellevw>
MikeSmith: not sure if that’s a project you’re working on, but github oauth is not working in FF or chrome

[19:25:28.0000] <estellevw>
it did work in Safari 8.0.7

[19:55:10.0000] <MikeSmith>
hi again estellevw

[19:55:15.0000] <MikeSmith>
sorry, got distracted

[19:55:40.0000] <MikeSmith>
estellevw: I got no clues about github oauth

[19:55:53.0000] <MikeSmith>
I thought you were working on your book

[19:56:08.0000] <MikeSmith>
I hope you've not had to abandon that for lack of funding

[19:57:29.0000] <estellevw>
TabAtkins: Safari 8, IE Edge 12, Firefox 42, Chrome 42 and Opera 31 all accept the transform-property with none in the comma separated list as valid, as if it were simply an  unrecognized or non-animatable property

[19:57:45.0000] <estellevw>
i am working on my book(s), but only part time

[19:57:49.0000] <MikeSmith>
k

[19:57:56.0000] <estellevw>
books do not pay for my lifestyle.

[19:58:03.0000] <estellevw>
my lifestyle includes eating

[19:58:05.0000] <MikeSmith>
heh

[19:58:05.0000] <estellevw>
;)

[19:58:07.0000] <MikeSmith>
yup

[19:58:51.0000] <estellevw>
i should write erotic thrillers. They sell better. But I find them less interesting.

[19:59:25.0000] <MikeSmith>
hahah

[20:00:16.0000] <MikeSmith>
maybe if you could become as famous as Chuck Tingle

[20:00:30.0000] <MikeSmith>
you need a kind of niche or angle for that market

[20:00:31.0000] <estellevw>
and if i were to write “50 shades of grey” it would be less than one page long, and all in hexidecimals

[20:00:39.0000] <MikeSmith>
hah

[20:03:17.0000] <MikeSmith>
little-known fact: Fifty Shades of Grey was actually written more than 10 years ago by Steven Shainberg, except that he called it "Secretary" and the main characters were James Spader and Maggie Gyllenhaal and it was roughly a gazillion times more interesting and original

[20:04:59.0000] <MikeSmith>
estellevw: anyway, as far as jobs go, not that I speak at all in any way for Mozilla, but knowing my friends there and the work they do, I can imagine Mozilla being a place where you'd find some interesting things to work on, and people to appreciate your work, and people whose work you can appreciate

[20:05:26.0000] <MikeSmith>
estellevw: you might want to chat up annevk or somebody about that

[20:06:59.0000] <MikeSmith>
and would love to have you at the W3C but don't know that W3C is able to open any new positions right now

[20:07:25.0000] <MikeSmith>
W3C/MIT might be able to, but I know we really can't right now in Japan, W3C/Keio

[20:08:04.0000] <MikeSmith>
all four of the W3C hosts have separate budgets, basically, and separate hiring processes and employement contracts, etc.

[20:08:17.0000] <estellevw>
that sounds fun.

[20:08:21.0000] <MikeSmith>
heh

[20:08:51.0000] <estellevw>
it’s hard to refer when offices are different cities, even more so with different budgets and policies

[20:09:00.0000] <MikeSmith>
yup

[20:12:24.0000] <estellevw>
TabAtkins: should the none/inherit/initial be treated as  if the property weren’t declared at all or as the default ‘all’?

[20:18:13.0000] <estellevw>
should the none/inherit/initial be treated as  if the property weren’t declared at all (so as if set to none) or as if set, but  default to ‘all’?

[20:35:56.0000] <estellevw>
oops, i was oding all my w3 #css questioins in the freenode #whatwg IRC channel. sorry

[22:46:53.0000] <TabAtkins>
estellevw: Neither, it should be treated as illegal (for violating the grammar) and ignored.

[22:47:31.0000] <TabAtkins>
estellevw: But since everyone seems to accept it, it's probably better to treat the spec as being wrong.

[22:48:11.0000] <annevk>
slightlyoff: see the open issues, I think we've nearly resolved that one

[22:59:07.0000] <estellevw>
TabAtkins: 3 browsers treat it as `all` and 2 treat it as it is a non-animatable property

[23:17:06.0000] <annevk>
morning estellevw, curious where you'll end up going :-)

[00:44:47.0000] <philipj>
annevk: is there a repo for resources.github.com? I want to fix bikeshed.css

[00:44:59.0000] <annevk>
philipj: https://github.com/whatwg/resources.whatwg.org

[00:45:10.0000] <annevk>
philipj: wait, resources.github.com?

[00:45:16.0000] <annevk>
philipj: I guess you mean whatwg.org?

[00:45:19.0000] <philipj>
annevk: yeah, sorry

[00:45:22.0000] <annevk>
ok

[00:45:33.0000] <philipj>
it's https://resources.whatwg.org/bikeshed.css I need to poke at

[00:47:04.0000] <nox>
jgraham: Thanks for adding me to the html5lib's team, but my immediate needs would rather be a review on https://github.com/html5lib/html5lib-tests/pull/69. :P

[00:52:14.0000] <Ms2ger>
/me looks

[00:54:28.0000] <Ms2ger>
r+

[01:02:43.0000] <annevk>
nox: ^

[01:23:46.0000] <Ms2ger>
Innovations for the document object model[1] are presented, interfaces DOMFactoryResolver and DOMFactory, towards a document object model 5 (DOM5). The DOMFactoryResolver interface is utilized to obtain DOMFactory factories with which to create objects implementing Element.

[01:29:46.0000] <zcorpan>
Ms2ger: wat?

[01:30:10.0000] <Ms2ger>
Adam Sobieski

[01:49:38.0000] <Ms2ger>
philipj, looks like I have two LGTMs on github, okay if I ignore your critic  comment? :)

[01:51:47.0000] <philipj>
Ms2ger: sure, if you don't mind testing the same thing twice

[01:52:14.0000] <philipj>
too much testing is usually not the problem

[01:53:23.0000] <annevk>
Ms2ger: pointer to DOM5?

[01:54:16.0000] <Ms2ger>
https://www.w3.org/community/argumentation/2015/09/21/document-object-model-5/

[01:57:14.0000] <nox>
Factories. :(

[01:57:18.0000] <nox>
Nooooo

[01:57:45.0000] <annevk>
nox: none of that is even remotely likely to happen

[01:57:56.0000] <nox>
/me was scared.

[02:30:23.0000] <zcorpan>
you keep using that word, "utilize"

[02:32:43.0000] <zcorpan>
i have no clue what problem Adam is trying to solve

[03:03:14.0000] <zcorpan>
philipj: why does webvtt have this custom webhook thing?

[03:05:39.0000] <philipj>
zcorpan: it started out with troubles with respec, like the server where it's hosted being down and scrolling to the wrong position

[03:06:03.0000] <philipj>
also, occasional breaking changes, so I wanted to control when we got a new respec version, by having it as a submodule

[03:06:34.0000] <philipj>
finally, I'm not a fan of the initial FOUC of respec specs

[03:06:59.0000] <jgraham>
s/of the initial FOUC // ?

[03:07:04.0000] <zcorpan>
yeah i'm totally going to bikeshed webvtt

[03:07:20.0000] <philipj>
jgraham: heh, yeah, that would also be true :)

[03:07:28.0000] <philipj>
zcorpan: I would recommend that, yeah

[03:07:51.0000] <philipj>
jgraham: there is one or two things that I like about respec, but I can't remember what they were any more

[03:08:10.0000] <philipj>
oh right, that it doesn't ask you to type out a manual id for your sections, like Bikeshed does :)

[03:08:20.0000] <zcorpan>
i wonder what the state of the art is for having the spec published. i suppose it's not checking in to CVS

[03:09:05.0000] <philipj>
zcorpan: heh, if you want to move it to github.io or something, that would be nice

[03:10:32.0000] <zcorpan>
i don't really care where it is, but i don't fancy maintaining webhook

[03:12:32.0000] <philipj>
I'll keep it running until it breaks, so it's not urgent, but getting off that infrastructure sure would be nice

[03:28:43.0000] <annevk>
zcorpan: if you were to move it to WHATWG there'd be a webhook still, but I could maintain it

[03:30:54.0000] <zcorpan>
annevk: ok, thx. i wouldn't mind moving to whatwg personally but i don't know what the rest of the webvtt people think of it

[03:40:41.0000] <annevk>
mkwst: what's the latest on https://github.com/whatwg/fetch/issues/45?

[04:23:31.0000] <mkwst>
annevk: I guess that's taken care of by `client`?

[04:24:55.0000] <mkwst>
Or, I guess the `origin` attribute on the request (which derives from `client`)?

[04:28:12.0000] <mkwst>
annevk: Also, when you have a few minutes, I've refactored https://w3c.github.io/webappsec/specs/powerfulfeatures/ to put a flag on the settings object (for SharedWorkers, but it was simpler to just use it everywhere). https://w3c.github.io/webappsec/specs/powerfulfeatures/#framework and

[04:28:13.0000] <mkwst>
https://w3c.github.io/webappsec/specs/powerfulfeatures/#settings-object-flag are the parts that really changed. The rest just moved around.

[05:03:41.0000] <annevk>
mkwst: yeah, I think client takes care of it

[05:03:56.0000] <annevk>
mkwst: will look at Secure Contexts later

[05:06:17.0000] <mkwst>
I'll close out the issue.

[05:06:23.0000] <mkwst>
No rush on secure contexts. It's not going anywhere.

[05:14:35.0000] <zcorpan>
MikeSmith: should https://github.com/w3c/web-platform-tests/pull/1922 be merged?

[05:16:27.0000] <MikeSmith>
zcorpan: no, that's waiting on me to make a different fix in the testtwf-website-srd docs

[05:16:54.0000] <MikeSmith>
which I will try to get soonish

[05:47:50.0000] <annevk>
mkwst: 3.1 step 1 doesn't make sense to me, I don't see why sandboxed content should not have a correct HTTPS state set

[05:48:25.0000] <mkwst>
HTTPS state is poorly defined. I don't think it's in HTML yet. I'm hedging my bets. :)

[05:49:04.0000] <annevk>
mkwst: well, but you are relying on it too

[05:49:09.0000] <mkwst>
Well, yes.

[05:49:14.0000] <annevk>
mkwst: this is the kind of thing that implementers hate...

[05:49:24.0000] <mkwst>
<-- implementer.

[05:49:40.0000] <annevk>
those that don't write the spec

[05:49:45.0000] <mkwst>
And yes, you're right. I hate it. So, are you going to integrate fetch with HTML in a way that makes it make sense? :)

[05:50:23.0000] <annevk>
well, https://www.w3.org/Bugs/Public/show_bug.cgi?id=27190 is still somewhat in an unclear state

[05:50:41.0000] <annevk>
but anyway, if that is fixed I don't think your algorithm would make sense per what I said above

[05:51:38.0000] <mkwst>
Assuming that https state is a thing that is well defined somewhere, dropping the unique origin bits is totally reasonable.

[05:51:56.0000] <mkwst>
Is that the only piece of the algorithm that doesn't make sense to you, or are you pointing to something deeper?

[05:53:27.0000] <annevk>
It also doesn't make sense as a flag, since at least as settings objects are defined today they only have corresponding algorithms

[05:54:59.0000] <mkwst>
Ok. Then perhaps I misunderstood our discussion around shared workers. I thought we were agreeing to add a flag to their settings objects to do the attachment check.

[05:58:39.0000] <mkwst>
Also: I remember now that the "origin of url" thing was meant to deal with `<iframe sandbox="allow-scripts" src="http://localhost/">`, which is delivered from a "potentially trustworthy" URL, but would have an "HTTPS state" of "none".

[06:09:17.0000] <annevk>
mkwst: why would that have an HTTPS state of none?

[06:09:36.0000] <mkwst>
Because it's not modernly encrypted? Or deprecatedly encrypted? It

[06:09:38.0000] <annevk>
mkwst: hmm I guess it does currently

[06:09:44.0000] <mkwst>
It's not https at all?

[06:09:59.0000] <annevk>
mkwst: well, data and blob URLs are not HTTPS either and we set it for those

[06:11:01.0000] <mkwst>
If the origin is inherited, that makes sense.

[06:11:55.0000] <mkwst>
(Note that `data` doesn't inherit the origin in Chrome, and isn't considered secure in this draft)

[06:12:46.0000] <annevk>
mkwst: "this draft" builds on top of a house of cards with cards missing, so that's very much unclear

[06:13:07.0000] <annevk>
mkwst: especially since Fetch does set HTTPS state to modern for certain data ULRs

[06:14:50.0000] <mkwst>
Ok. Chrome doesn't consider `data` URLs secure. I'll have to look at Fetch to see what it considers secure. :)

[06:15:41.0000] <mkwst>
Help me find cards. *shrug* It seems like the thing that's missing is the analog to "https state" for a settings object.

[06:16:44.0000] <mkwst>
Conceptually, that seems straightforward to inherit the Response's https state down into the document or worker which uses the response to create a settings object/context/etc.

[06:22:52.0000] <mkwst>
(e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=27147)

[07:00:36.0000] <smaug____>
annevk: do you think you'd have time to look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=28920

[07:01:40.0000] <smaug____>
(gandalf needs it for some localization stuff, but before changing Gecko, I'd like to see the spec changed)

[07:18:16.0000] <MikeSmith>
mkwst: does Chrome actually yet support doing SRI using the integrity member of the options to fetch()?

[07:18:41.0000] <MikeSmith>
as opposed to just the integrity markup attribute

[07:19:23.0000] <mkwst>
MikeSmith: I don'

[07:19:25.0000] <mkwst>
I don'

[07:19:26.0000] <mkwst>
...

[07:19:31.0000] <mkwst>
I can't type. And I don't know.

[07:19:39.0000] <mkwst>
Let me look. If Joel implemented it, I didn't review it.

[07:20:16.0000] <MikeSmith>
k

[07:20:32.0000] <MikeSmith>
I can't tell for certain from https://code.google.com/p/chromium/issues/detail?id=355467

[07:20:46.0000] <mkwst>
Looks like the attribute is there. Let's see if it's wired up to anything.

[07:21:26.0000] <MikeSmith>
I see https://code.google.com/p/chromium/issues/detail?id=355467#c27 "we have shipped SRI as per the spec only for <script> and <link rel="stylesheet"> elements" but that's ambiguous (in that it could just mean "but not for other elements")

[07:24:04.0000] <mkwst>
MikeSmith: Looks like it might be wired up. :)

[07:25:12.0000] <MikeSmith>
cool

[07:25:16.0000] <MikeSmith>
thanks

[07:25:31.0000] <MikeSmith>
(I'm updating that MDN page with more specific details)

[07:26:27.0000] <mkwst>
MikeSmith: Looks like it landed ~3 weeks ago: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27190

[07:28:57.0000] <JonathanNeal>
TabAtkins: pardon the diet PR, but I hope it makes the update a little easier. I wasn’t sure what else to touch. https://github.com/tabatkins/specs/pull/42

[07:40:47.0000] <annevk>
Hmm, smaug is offline

[07:47:36.0000] <Ms2ger>
* smaug will be less offline during evenings this week because of hiff.fi

[07:56:52.0000] <annevk>
So I wonder if fixing ganfalf's issue means queueing tasks or whether there's something more involved needed

[08:04:00.0000] <annevk>
I cannot actually find a problem with the standard

[08:04:07.0000] <annevk>
/me left a comment on the bug

[09:48:45.0000] <MikeSmith>
has anybody tried navigator.webkitGetUserMedia in Safari 8 and managed to get it to work?

[09:49:21.0000] <MikeSmith>
I get a "not supported" error when I try it

[12:51:53.0000] <smaug____>
annevk: hopefully my comment clarified a bit where the issue is with defer scripts

[12:52:09.0000] <smaug____>
I don't recall if there was something also with async

[15:00:48.0000] <MikeSmith>
/me wonders if smaug____ is also a filmmaker

[15:02:46.0000] <smaug____>
hmm

[15:03:17.0000] <smaug____>
at least I'm not aware of that

[16:28:25.0000] <rniwa>
hayato: yt?

[16:28:52.0000] <rniwa>
Domenic: yt?

[16:29:05.0000] <Domenic>
rniwa: yes

[16:29:21.0000] <rniwa>
Domenic: does the event path supposed to include shadow root?

[16:29:35.0000] <rniwa>
Domenic: it looks like it should according to the latest editor's draft

[16:29:39.0000] <rniwa>
annevk: ^

[16:29:51.0000] <Domenic>
rniwa: I think it was renamed to deepPath and does, for open shadow trees

[16:30:08.0000] <rniwa>
Domenic: I'm not talking about the property `deepPath`

[16:30:09.0000] <Domenic>
rniwa: oh, you mean the shadow root node specifically? yes, i can't imagine why that would be omitted.

[16:30:25.0000] <rniwa>
Domenic: but rather whether the event will be fired on the shadow root or not

[16:30:30.0000] <Domenic>
i see

[16:30:31.0000] <rniwa>
Domenic: and it seems the answer is yes

[16:30:49.0000] <Domenic>
I don't remember anyone ever bringing this up, but it does seem like the intention and it seems reasonable.

[16:32:39.0000] <rniwa>
Domenic: okay, thanks

[16:36:31.0000] <dglazkov>
yep, that should be okay

[16:36:57.0000] <rniwa>
/me is writing tests

[16:43:59.0000] <MikeSmith>
annevk: https://twitter.com/amirrajan/status/646380685045796864

[16:44:13.0000] <MikeSmith>
annevk: http://a/%%30%30

[16:44:54.0000] <MikeSmith>
rniwa: do you know, does Safari not support getUserMedia at all? even prefixed?

[16:46:04.0000] <rniwa>
MikeSmith: we don't support it at all

[16:46:08.0000] <rniwa>
MikeSmith: not even prefixed

[16:46:23.0000] <MikeSmith>
ok

[16:47:53.0000] <MikeSmith>
I get different errors for it in nightly WebKit vs Safari 8 stable, which made me wonder a bit ("permission denied" in WebKit vs "undefined" in stable)

[16:48:47.0000] <MikeSmith>
smaug____: was wondering given Ms2ger comment about the film festival

[16:48:49.0000] <rniwa>
oh that's strange.

[16:49:40.0000] <MikeSmith>
rniwa: yeah dunno whyーdidn't investigate beyond that

[16:50:32.0000] <rniwa>
MikeSmith: okay, thanks for letting me know!

[16:50:54.0000] <MikeSmith>
cheers

[16:56:54.0000] <smaug____>
MikeSmith: oh. just a film festival around here

[16:57:42.0000] <smaug____>
/me could recommend "The Brand New Testament"


2015-09-23
[17:19:56.0000] <MikeSmith>
/me googles The Brand New Testament

[17:20:38.0000] <MikeSmith>
/me sees Catherine Deneuve so that's a definite plus

[22:50:28.0000] <Krinkle>
Hm.. is it standards-specified that there will be own properties on localStorage for all stores keys?

[22:50:40.0000] <Krinkle>
I'm trying to find a good arguments for why Object.keys(localStorage) is bad.

[22:51:19.0000] <Krinkle>
I can't find it explicitly on https://html.spec.whatwg.org/multipage/webstorage.html#storage-2 except for the sentence "The supported property names on a Storage object are the keys of each key/value pair currently present in the list associated with the object" - I'm not sure what that sentence even means.

[23:08:56.0000] <annevk>
Krinkle: that's IDL language for saying it has own properties

[23:09:01.0000] <annevk>
Krinkle: iirc

[23:14:12.0000] <Krinkle>
annevk: thx.

[23:14:15.0000] <Krinkle>
Quite fascinating behaviour

[23:14:44.0000] <Krinkle>
localStorage.setItem('setItem', new Date()); Object.keys(localStorage); // [ setItem ] and yet localStorage.setItem; // [native]

[23:14:53.0000] <Krinkle>
so its there but the inherited one does overlap

[23:15:11.0000] <Krinkle>
Is that standards, too :D ?

[23:17:53.0000] <annevk>
MikeSmith: https://twitter.com/annevk/status/646569118485901312

[23:18:26.0000] <MikeSmith>
/me looks

[23:18:39.0000] <MikeSmith>
yeah I figured

[23:18:50.0000] <MikeSmith>
cool that it crashes the entire browser though

[23:18:59.0000] <annevk>
Krinkle: yeah, due to lack of OverrideBuiltins which we cannot add at this point iirc

[23:19:03.0000] <annevk>
Krinkle: [OverrideBuiltins]

[23:19:13.0000] <MikeSmith>
hat tip to amirrajan for finding that bug

[23:26:40.0000] <Krinkle>
annevk: Ah, I see. Looks like github/whatg has no mention of it, but there are a few matches in w3c https://github.com/search?q=OverrideBuiltins+%40w3c&type=Code

[23:27:26.0000] <Krinkle>
https://w3c.github.io/html-reference/form.html#form-interface

[23:28:42.0000] <Krinkle>
But yeah, that's an undefined IDL ref.

[23:33:22.0000] <Krinkle>
annevk: Found it. https://github.com/heycam/webidl/blob/HEAD/lc2.txt#L164

[23:44:58.0000] <annevk>
Krinkle: https://heycam.github.io/webidl/ is the IDL specification

[23:45:08.0000] <Krinkle>
Yeah

[23:45:26.0000] <Krinkle>
So OverrideBuiltins is part of that standard, but not allowed for partial interfaces yet.

[23:45:33.0000] <Krinkle>
not sure if that's relevant though

[23:45:34.0000] <annevk>
Krinkle: and the HTML Standard uses OverrideBuiltins, e.g., as part of DOMStringMap

[23:45:55.0000] <Krinkle>
Ah, it's already being used. cool

[23:46:55.0000] <annevk>
Krinkle: I don't think we can change localStorage though

[23:47:00.0000] <Krinkle>
github search didn't pick up on that, presumably because whatwg/html:/source is too large or extensionless

[23:47:11.0000] <annevk>
Krinkle: also not sure whether we want to, localStorage should not be used

[23:47:40.0000] <Krinkle>
I've created https://github.com/whatwg/html/issues/183 for now

[23:47:52.0000] <Krinkle>
I'm entirely satisfied if it's a no, but would like a paper trail for it.

[23:51:15.0000] <Krinkle>
annevk: Well, that's easy to say. There doesn't seem to be a good alternative at the moment. At least we're using it behind a few abstraction layers, but in that layer I noticed some code using Object.keys() and it looked quite odd. Since people usually use a .length for-loop calling .key()

[00:10:35.0000] <annevk>
Krinkle: yeah, I guess it'll be hard to move away from existing usage

[00:10:43.0000] <annevk>
Krinkle: alternative is IDB

[00:11:32.0000] <Krinkle>
Yeah, but that requires a million lines of code to set and get a single key last I tried. Having said that, I've not looked at it properly. we have an open task to migrate to that.

[00:11:45.0000] <Krinkle>
But less support-ish, but we could always fallback to localStorage. There's a few libraries that do that.

[00:11:58.0000] <Krinkle>
Though the async-ness means we can't easily migrate existing code.

[00:12:09.0000] <Krinkle>
I wish localStorage was async from the get-go, would've encouraged better code.

[00:17:37.0000] <annevk>
Now I'm conflicted: https://github.com/whatwg/fetch/issues/97#issuecomment-142449720

[00:18:04.0000] <annevk>
Krinkle: might be a couple of order of magnitudes less

[00:18:38.0000] <annevk>
Krinkle: yeah, the synchronous IO bit is the main problem with localStorage

[00:38:26.0000] <zcorpan>
https://lists.w3.org/Archives/Public/public-texttracks/2015Sep/0013.html

[01:17:25.0000] <annevk>
zcorpan: interesting

[01:17:54.0000] <annevk>
zcorpan: feel free to create whatwg/webvtt

[01:18:13.0000] <annevk>
zcorpan: and then ping Hixie about adding the domain to my account

[01:19:43.0000] <annevk>
https://twitter.com/zcorpan/status/646594862616309760 :-)

[01:29:52.0000] <annevk>
zcorpan: perhaps ask philipj if he can manage to keep the webvtt version history somehow

[01:34:08.0000] <philipj>
annevk, zcorpan, just make a fork of the existing repo I guess?

[01:34:50.0000] <annevk>
philipj: oh, heh, I thought there was still only the CVS one

[01:35:19.0000] <philipj>
annevk: no, it's not that bad, the CVS is just the mechanism for publishing to http://dev.w3.org/html5/webvtt/

[01:35:32.0000] <philipj>
s/the//

[01:38:41.0000] <MikeSmith>
gsnedders: fyi http://stackoverflow.com/questions/32731479/lxml-html5parser-ignores-namespacehtmlelements-false-option

[01:39:15.0000] <MikeSmith>
gsnedders: I got lazy about trying to troubleshoot it myself. Maybe I can get somebody else to do it for me

[01:40:58.0000] <MikeSmith>
philipj: I'd suggest please that the group quit publishing that http://dev.w3.org/html5/webvtt/ URL. We can just set up a redirect from there to some saner place.

[01:42:13.0000] <MikeSmith>
I hope to see the day when we're not longer actually versioning anything at http://dev.w3.org but instead it exists just for redirects of old URLs to keep them from breaking

[01:42:23.0000] <philipj>
MikeSmith: zcorpan is now the editor, but I'd be delighted to see the spec published on webvtt.spec.whatwg.org (or w3c.github.io/webvtt) with a redirect

[01:42:29.0000] <MikeSmith>
yeah

[01:42:39.0000] <MikeSmith>
let's do that

[01:42:57.0000] <MikeSmith>
doesn't sound like anybody in the group objects to it

[01:43:23.0000] <annevk>
philipj: perhaps it's better than to just move the repo?

[01:43:46.0000] <philipj>
annevk: not sure if it's possible to move a repo between organizations, but if it is, sure

[01:44:03.0000] <annevk>
I think so, though haven't done it before

[01:44:10.0000] <zcorpan>
is it considered moved if one does a fork and then remove the original?

[01:44:30.0000] <philipj>
zcorpan: no, I can't imagine that would set up the redirects that a move results in

[01:44:45.0000] <zcorpan>
ah ok

[01:45:23.0000] <zcorpan>
MikeSmith: what is the "best" way to publish stuff on TR/ these days?

[01:45:36.0000] <MikeSmith>
autopublish thing

[01:45:48.0000] <MikeSmith>
called "Echidna"

[01:46:04.0000] <annevk>
mkwst: I'm not entirely comfortable leaving the document bit as an open issue for HTTPS state

[01:46:15.0000] <zcorpan>
MikeSmith: ok

[01:46:17.0000] <MikeSmith>
zcorpan: I am happy to help anybody/any group get set up to do that

[01:46:30.0000] <MikeSmith>
once you have it set up, you can push to TR/ space at will

[01:46:31.0000] <mkwst>
annevk: Ok. Do you have suggestions? :)

[01:46:47.0000] <philipj>
zcorpan: whenever we asked to get that autopublished for /TR/webvtt1 we got pushback because the TTWG wants to OK every revision

[01:47:05.0000] <MikeSmith>
philipj: oh geez

[01:47:08.0000] <philipj>
so I just opted to never take the initiative to update /TR/webvtt1 at all

[01:47:20.0000] <zcorpan>
philipj: :-(

[01:47:28.0000] <MikeSmith>
I think they just need to be politely told, sorry, no

[01:47:36.0000] <annevk>
mkwst: it seems it is defined when a document is created as a result of navigation

[01:48:07.0000] <philipj>
MikeSmith: do you know how to be polite?

[01:48:40.0000] <philipj>
zcorpan: the one thing that makes it less terrible is the quite prominent warning/redirect at the bottom of http://www.w3.org/TR/webvtt1/

[01:48:53.0000] <philipj>
also, that not much has changed normatively since the last update

[01:49:42.0000] <MikeSmith>
philipj: well, scratch the politeness plan actuallyーI can instead bring it to Philippe's attention and he won't bother to be polite to them

[01:50:21.0000] <philipj>
MikeSmith: I'm pretty sure that he was on CC on these discussions

[01:50:37.0000] <MikeSmith>
well the autopublishing thing is Philippe's project, and he's a very strong advocate for groups to use it

[01:50:53.0000] <philipj>
But my memory is now unclear and the discussions not in public, so better to approach it as a new question rather than "Y U NO AUTOPUBLISH?!"

[01:50:59.0000] <MikeSmith>
and one group cannot block another group from doing whatever it wants

[01:51:26.0000] <philipj>
MikeSmith: /TR/webvtt1 is published "by" the TTWG

[01:51:41.0000] <MikeSmith>
they can make a formal objection to some decision but I am pretty sure I already know the Director would not be sympathetic to an FO around this

[01:51:46.0000] <MikeSmith>
ah

[01:51:48.0000] <MikeSmith>
ok

[01:52:17.0000] <philipj>
there is no other WG involved with WebVTT, there's just the text tracks CG

[01:52:58.0000] <MikeSmith>
oh christ this "joint deliverable" stuff is without an exceptions always a bad idea

[01:53:05.0000] <MikeSmith>
philipj: OK

[01:53:10.0000] <annevk>
mkwst: however, a document as result of navigation can be either the result of a request or a response (and sometimes I think a Document object gets reused)

[01:54:04.0000] <MikeSmith>
hmm well Dave Singer is the co-chair of that WG and he is always flexible and helpful in my experience

[01:54:26.0000] <MikeSmith>
so maybe we can just ask Dave to please sort it out so that it can be autopublished

[01:55:31.0000] <philipj>
MikeSmith: sure, it's worth another try, previous discussions were never initiated by me or Silvia

[01:55:35.0000] <roc>
annevk: why haven't we added a simple promise-based wrapper API to IndexedDB which covers the localStorage usecases in a convenient way?

[01:55:38.0000] <zcorpan>
MikeSmith: do you have the right Powers to move the repo? it seems i don't have a settings button

[01:56:13.0000] <MikeSmith>
zcorpan: hang on

[01:56:13.0000] <zcorpan>
https://help.github.com/articles/transferring-a-repository/

[01:56:14.0000] <annevk>
roc: transactions and promises were hard to reconcile iirc

[01:56:54.0000] <MikeSmith>
zcorpan: try now

[01:57:08.0000] <roc>
localStorage doesn't even have transactions so I don't see why that would block things

[01:57:19.0000] <zcorpan>
MikeSmith: settings button appeared

[01:57:24.0000] <MikeSmith>
super

[01:57:44.0000] <annevk>
roc: https://gist.github.com/inexorabletash/c8069c042b734519680c has some ideas

[01:58:14.0000] <annevk>
roc: IDB has transactions so you'd break that invariant and it would no longer be a "wrapper"

[01:58:42.0000] <roc>
you just put every operation in its own transaction

[01:59:07.0000] <zcorpan>
hmm. i suppose i don't have admin rights in whatwg. annevk?

[01:59:46.0000] <annevk>
zcorpan: you do, you're in Owners

[02:00:31.0000] <zcorpan>
oh, i wrote "w3c" instead of "webvtt" in the "write the repo name to confirm" field

[02:00:35.0000] <roc>
I guess the argument in https://groups.google.com/forum/#!msg/mozilla.dev.gaia/g5_eOE7YHWw/s8dH40HC8lsJ is that you actually need transactions and people who use localStorage without them are exchanging reliability for convenience.

[02:02:37.0000] <annevk>
roc: technically without the storage mutex there's a lot of potential for weird behavior with localStorage and cookies, but I haven't seen folks run into it in practice

[02:02:54.0000] <roc>
yeah

[02:05:47.0000] <annevk>
roc: but I'm not sure why we still haven't added a new simple API

[02:06:17.0000] <annevk>
roc: I think maybe in part folks are hesitant to add yet another storage API and in part some folks have been pushing for figuring out the primitives underlying IDB and exposing those first...

[02:06:23.0000] <zcorpan>
annevk: ok i've moved the repo and created a Team for it

[02:06:36.0000] <annevk>
roc: which I think https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191 is about

[02:07:46.0000] <annevk>
zcorpan: okay, so once the domain name is setup I can make sure publishing happens automatically

[02:08:02.0000] <annevk>
zcorpan: and then I guess you might want to configure a Twitter account for it and such

[02:08:18.0000] <zcorpan>
Hixie: can you please create webvtt.spec.whatwg.org and add it to annevk's account?

[02:37:13.0000] <mkwst>
annevk: Sorry, had to run out.

[02:37:51.0000] <mkwst>
annevk: I'm trying to trace the navigation pieces to see where we have a response. It looks like we will end up in the "initialize" mechanism regardless of how we git the bits we're parsing.

[02:40:34.0000] <mkwst>
Step 15 of https://html.spec.whatwg.org/#navigating-across-documents fetches the data, then step 24 farms it out to one of HTML or XML or whatever, each of which ends up calling "initialize the Document object".

[02:41:17.0000] <annevk>
mkwst: yeah, that matches my understanding

[02:41:40.0000] <annevk>
mkwst: there's something with history traversal where an existing Document object can get reused, but in that case it should already have the HTTPS state set to something

[02:41:58.0000] <mkwst>
annevk: Right. I think we only care about this when we create a new Document object.

[02:42:43.0000] <annevk>
mkwst: it might be better to associate this with the Window object though, since for many Document objects this state does not make sense

[02:43:00.0000] <annevk>
mkwst: e.g., why should new Document() have an HTTPS state?

[02:43:02.0000] <mkwst>
sure. that would match the state on the worker.

[02:43:07.0000] <mkwst>
that makes sense.

[02:43:48.0000] <annevk>
mkwst: the only tricky thing with that seems to be document.open(), which can replace the Window object while keeping the Document object

[02:44:10.0000] <annevk>
mkwst: I guess you'd have to copy the state across there

[02:44:18.0000] <mkwst>
annevk: In that case, yeah, we'd copy the state over.

[02:50:15.0000] <JakeA>
Domenic: any docs on the tc39 discussion on cancellable promises?

[02:58:24.0000] <smaug____>
annevk: then that part of the spec is totally unreadable

[02:59:32.0000] <annevk>
smaug____: I'm not going to argue it's great

[03:00:12.0000] <annevk>
smaug____: but I'm not sure I would have done a better job given the kind of insane model Hixie has reverse engineered

[03:01:40.0000] <smaug____>
hmm, "spin the event loop" looks buggy

[03:01:53.0000] <smaug____>
"Queue a task to continue running these steps" o_O ?

[03:03:13.0000] <annevk>
smaug____: perhaps we could refactor that so that spin the event loop instead takes a "task" to run

[03:03:17.0000] <annevk>
smaug____: or a set of steps

[03:03:56.0000] <annevk>
smaug____: that might make it a bit more readable to programmers

[03:05:58.0000] <smaug____>
so random other tasks might run between 8 and 10

[03:06:00.0000] <smaug____>
hmm

[03:06:42.0000] <smaug____>
so the algorithm wants to effectively clear task queue from anything there was when "spin the event loop" was called

[03:06:59.0000] <smaug____>
and more

[03:07:48.0000] <smaug____>
anything the scripts added during that microtask checkpoint

[03:11:02.0000] <annevk>
"spin the event loop" basically seems like "wait while running the event loop until X is true and then when X is true queue a task to do my thing"

[03:11:23.0000] <annevk>
However, only X is an explicit argument, "my thing" is a tad more hand wavy

[03:15:39.0000] <smaug____>
/me is pretty sure this isn't anything what browsers do

[03:15:58.0000] <smaug____>
the sync even loop spinning there

[03:17:23.0000] <annevk>
smaug____: what do we do instead?

[03:18:56.0000] <annevk>
smaug____: or more interesting, what's observably different?

[03:21:23.0000] <smaug____>
"wait for the goal and continue" is probably closer. And in case of defer scripts, not sure what wk/blink do, but run defer scripts when document and defer scripts have been loaded - right before DOMContentLoaded

[03:21:44.0000] <smaug____>
spinning the event loop between running defer scripts is definitely observable

[03:23:04.0000] <annevk>
MikeSmith: happy b-day! 🎉

[03:24:55.0000] <annevk>
smaug____: okay, so you mean that Firefox waits until all <script defer> have been loaded

[03:25:26.0000] <annevk>
smaug____: what if a <script defer> inserts another <script defer>? I guess that doesn't work the same perhaps...

[03:25:52.0000] <annevk>
ah yeah, wouldn't be parser inserted

[03:28:55.0000] <MikeSmith>
annevk: thanks ✌️

[03:34:00.0000] <smaug____>
annevk: so Gecko has a queue for defer scripts. non-empty queue block DOMContentLoaded to fire

[03:34:25.0000] <smaug____>
but when we process defer scripts, we do it in a loop until there are no other loaded scripts

[03:34:38.0000] <smaug____>
and then wait for loading if there is something to load

[03:34:55.0000] <smaug____>
I guess that could change so that each defer script uses it own task

[03:35:15.0000] <smaug____>
that would be perhaps the sanest also from spec point of view

[03:36:29.0000] <annevk>
that's what the spec does, it just doesn't wait for all of them to load first

[03:36:38.0000] <annevk>
just waits for the parser to stop

[03:38:05.0000] <smaug____>
hmm, true

[03:38:26.0000] <smaug____>
the sync event loop spinning just harms readability a bit

[03:38:55.0000] <smaug____>
ok, let me write a gecko patch

[03:39:02.0000] <smaug____>
need to also change microtask handling

[03:39:23.0000] <smaug____>
/me wonders when html spec got different microtask handling from the original mt

[03:40:01.0000] <smaug____>
I guess it needs it because of using sync event loop spinning so often

[03:46:25.0000] <annevk>
smaug____: maybe when it started to be used for more than just mutation observers?

[03:46:55.0000] <annevk>
smaug____: I'm happy to make the event loop spinning more readable

[03:47:34.0000] <annevk>
smaug____: e.g. by passing in the steps to be run when the goal is met, rather than doing that in the somewhat weird way it is done now

[03:47:49.0000] <smaug____>
well, at least that mysterious ''until X" param could be improved

[03:48:03.0000] <smaug____>
it certainly doesn't sound like a param to the algorithm

[03:48:13.0000] <smaug____>
it sounds like a condition

[03:48:24.0000] <smaug____>
either while or do-while condition

[03:50:17.0000] <annevk>
smaug____: something like "Run spin the event loop with goal /goal/"?

[03:50:37.0000] <smaug____>
yes, something like that

[04:10:02.0000] <gsnedders>
MikeSmith: did you trying prodding with pdb, btw?

[04:43:50.0000] <espadrine>
related to html tokenization, shouldn't the HYPHEN-MINUS case indicate what state to switch to here? https://html.spec.whatwg.org/multipage/syntax.html#comment-end-state

[04:44:56.0000] <espadrine>
I'm used to seeing it specified everywhere

[04:48:28.0000] <zcorpan>
espadrine: it's not specified everywhere. when it isn't it means to stay in the same state :-)

[04:48:58.0000] <espadrine>
thanks!

[05:06:04.0000] <annevk>
smaug____: okay, I guess that can be done, not super high priority for now though

[05:06:19.0000] <annevk>
smaug____: there's some bigger problems with the event loop, such as lack of ES6 integration

[05:06:43.0000] <smaug____>
yeah, lack of defining how Promises should work

[05:43:25.0000] <MikeSmith>
gsnedders: did not yet pdb it yet, no. But it's been at least 2 weeks since I first noticed the problem, and I've not made time to investigate it further

[06:07:57.0000] <philipj>
zcorpan: I'm taking webvtt-webhook offline as I suppose it will never again be pinged

[06:11:44.0000] <zcorpan>
philipj: sounds good. i suppose it's broken with the move

[06:56:35.0000] <annevk>
philipj: what did that webhook do?

[06:57:11.0000] <philipj>
annevk: it generated a static copy of the spec using PhantomJS, then committed that to CVS

[06:57:26.0000] <annevk>
philipj: ah okay

[06:57:50.0000] <annevk>
philipj: so yeah, I guess we should setup webvtt.spec... and then just redirect that old copy

[06:58:02.0000] <philipj>
annevk: yep, MikeSmith says he can do the redirect

[06:59:22.0000] <philipj>
zcorpan: but if you don't want to check in the generated spec, then you'll still need some webhook to generate it from source

[06:59:49.0000] <philipj>
for mediasession I just check in the generated output, I kind of like seeing when Bikeshed made everything change

[07:00:53.0000] <zcorpan>
i could go either way with checking in generated version. in the csswg we typically just check in the source and have bikeshed run on the server, regenerating all the specs as necessary

[07:02:46.0000] <gsnedders>
MikeSmith: k

[07:02:52.0000] <gsnedders>
MikeSmith: am ill, so unlikely to dig recently

[07:02:58.0000] <gsnedders>
MikeSmith: recently? soon

[07:56:36.0000] <Mangle_Kawaii>
holis

[08:05:15.0000] <annevk>
zcorpan: until Domenic spreads the setup that Streams has I would prefer it if you check in the generated version too

[08:05:26.0000] <zcorpan>
annevk: sure

[08:05:32.0000] <annevk>
zcorpan: that way I can just curl/wget that from the server

[08:09:00.0000] <annevk>
zcorpan: the other thing that'd be useful if you kept the structure flat

[08:09:31.0000] <annevk>
zcorpan: no directories

[08:09:55.0000] <zcorpan>
annevk: ok. why?

[08:11:12.0000] <annevk>
zcorpan: easier to setup sync

[08:11:33.0000] <annevk>
zcorpan: that is, I can copy my existing script :-)

[08:15:50.0000] <zcorpan>
annevk: ok sure

[08:19:27.0000] <zcorpan>
/me gotta go

[09:14:52.0000] <Domenic>
annevk: MikeSmith: sorry I haven't had much time for reviews lately, but today should be good.

[09:15:03.0000] <annevk>
Domenic: not at TC39?

[09:15:22.0000] <annevk>
Domenic: prioritize MikeSmith's work, I'm in no rush

[09:15:24.0000] <Domenic>
annevk: at TC39, but today's topics look like I should have some in between time for reviews.

[09:16:06.0000] <Domenic>
Excited about getting URL straightened out though.

[09:24:45.0000] <annevk>
Domenic: slowly, but yes

[09:25:35.0000] <annevk>
Domenic: I guess I'll do Location too before we change that into distinct same-origin and cross-origin objects

[09:26:03.0000] <annevk>
Domenic: still need to think a bit about <a> and <area>, maybe tomorrow

[10:47:13.0000] <TabAtkins>
JonathanNeal: I just pushed the changes to Nesting.

[10:51:13.0000] <JonathanNeal>
Hurray! I'm out sick today, but anything I should take attention to?

[10:51:32.0000] <TabAtkins>
Nah, it's exactly what we talked about before.

[11:01:02.0000] <rbyers>
annevk: Regarding https://github.com/RByers/EventListenerOptions/issues/20, perhaps IRC (or a conference call if necessary) would be a more productive forum?

[11:01:35.0000] <rbyers>
.. It really sounds like we have the same end goal here, right?  Make it easier for developers to reason about the performance implications of their handlers, while allowing more pages to be fast?

[11:02:14.0000] <TabAtkins>
rbyers: I'm opposed to that goal.

[11:02:33.0000] <TabAtkins>
I prefer artisan pages, hand-crafted and slowly enjoyed on your porch on a lazy Sunday morning.

[11:02:53.0000] <rbyers>
TabAtkins: Ok, I guess I was wrong about IRC being a more productive discussion forum ;-)

[11:03:01.0000] <TabAtkins>
^_^

[11:06:19.0000] <jsbell>
roc, annevk: You may also like https://gist.github.com/inexorabletash/280016e79188b6a28247

[13:35:13.0000] <MikeSmith>
whoah

[13:35:47.0000] <MikeSmith>
jsbell: I like the part where you say, "For those times when you don't care about your data getting corrupted, use this!"

[13:38:37.0000] <jsbell>
MikeSmith: ???

[13:39:17.0000] <MikeSmith>
jsbell: trolling )

[13:39:33.0000] <MikeSmith>
but that does seem like a possible footgun

[13:40:20.0000] <MikeSmith>
I would wonder, if it's made available, what's to prevent Web devs from using it when they should instead really be using the transactional API

[13:41:15.0000] <jsbell>
MikeSmith: indeed. You can lead a developer to ACID but...

[13:41:25.0000] <MikeSmith>
but instead they use this and end up muffing up their data and then they come screaming about Y U hurt my data??!!

[13:41:34.0000] <MikeSmith>
jsbell: yup

[16:14:44.0000] <Domenic>
Anyone understand hgroup enough to help with https://github.com/whatwg/html/issues/115 ?

[16:22:42.0000] <zewt>
well that's lovely, updated debian and a bunch of scripts broke because apparently lxml.cssselect is now case-sensitive

[16:23:14.0000] <TabAtkins>
SimonSapin: ^^^ what zewt just said; is lxml.cssselect case-sensitive somehow now?

[16:25:14.0000] <Domenic>
MikeSmith: what's a good way to trigger a build error deep in the file?

[16:25:26.0000] <zewt>
doc = html5lib.parse(html, treebuilder='lxml'); results = CSSSelector('#id A')(doc), had to change A to a (guess it could also be a change in the parser)

[16:25:38.0000] <MikeSmith>
Domenic: put in a stray end tag maybe

[16:26:03.0000] <Domenic>
sounds good

[16:26:54.0000] <Domenic>
Hmm if [[ "$WATTSI_RESULT" -ne "0" ]]; then => syntax error in conditional expression

[16:27:11.0000] <Domenic>
most of the conditionals in the file do not use [[ ]]

[16:27:34.0000] <Domenic>
oh nevermind

[16:27:37.0000] <Domenic>
I just mismatched my braces

[16:28:46.0000] <MikeSmith>
yeah we really should better be using the [[ ]] extended form everywhere, actually

[16:30:13.0000] <MikeSmith>
[[ ]] is just less portable. But if you use it even once in a script you might as well always use it. And there are cases the definitely require it

[16:30:17.0000] <Domenic>
MikeSmith: here's some output using the build server, going to try local now https://gist.github.com/domenic/68b7ab882afb6e6586d4

[16:30:26.0000] <MikeSmith>
/me looks

[16:30:45.0000] <MikeSmith>
so that looks correct

[16:30:51.0000] <MikeSmith>
that is expected output, right?

[16:31:13.0000] <MikeSmith>
damn look at those line numbers

[16:31:18.0000] <Domenic>
ok works

[16:31:31.0000] <Domenic>
yep

[16:31:31.0000] <Domenic>
just confirming it met what you expected

[16:31:31.0000] <Domenic>
wow local wattsi is fast

[16:31:35.0000] <MikeSmith>
103882 vs 105129 is quite a diffence but looks correct

[16:31:59.0000] <MikeSmith>
yeah Hixie's wattsi code is fairly amazing in terms of performance

[16:32:03.0000] <Domenic>
yeah 103882 is the correct source line i messed with

[16:32:17.0000] <MikeSmith>
his html parser is as fast as any other one out there

[16:38:04.0000] <MikeSmith>
Domenic: rock and roll

[16:38:14.0000] <Domenic>
\o/

[16:38:22.0000] <MikeSmith>
will rebase and squash the repo-switcher one shortly

[16:39:53.0000] <MikeSmith>
before that I need to clean up because I have to head into the office today and I'm in a somewhat Stallman-esque personal hygiene state from having been working at home so far all this week

[16:42:37.0000] <jgraham>
I didn't realise that was like Libraries of Congress for dirt

[16:43:21.0000] <Domenic>
lol i know the feeling

[16:45:20.0000] <wanderview_pto>
JakeA: is this still expected to work? https://jakearchibald.github.io/offline-wikipedia/?Hulk_Hogan

[16:46:07.0000] <wanderview_pto>
JakeA: I get a 404 from this resource load:  https://wikipedia-cors.appspot.com/en.m.wikipedia.org/wiki/Hulk_Hogan?action=render

[16:49:42.0000] <wanderview_pto>
I haven't pretty-printed the sw.js, but it appears to be passing that URL through from the fetch event

[16:55:37.0000] <wanderview_pto>
JakeA: ah, it seems maybe the gh-pages branch just hasn't been updated in 5 months... I don't see appspot referenced from the main branch


2015-09-24
[18:00:03.0000] <Hixie>
Domenic: oh wow are you doing the fixing the line numbers thing?

[18:04:45.0000] <Domenic>
Hixie yeah but it's hackier than you'd think we just re-run with the original source and if it spits out errors we give you those too.

[19:11:49.0000] <MikeSmith>
Domenic: repo-chooser PR squashed and rebased and repushed to the PR branch

[19:17:54.0000] <MikeSmith>
Hixie: yeah especially given how fast wattsi is, just doing a second pass with the raw source seemed most practical (rather than say, trying to teach wattsi some magic as far as how to determine the line offset to the raw source so that we could do it in one pass)

[19:20:11.0000] <MikeSmith>
Domenic: btw about the hgroup example in https://github.com/whatwg/html/issues/115, I think the effect of that is, the OP's second "List Title 1 Alternative" heading there (the second of what the OP calls "equivalent headings") is that in any outline, that second heading is not going to appear

[19:22:51.0000] <MikeSmith>
Domenic: I'm not sure the OP realizes it will have that effect, or wants it. I would be wrong but in terms of the outline algorithm there is no such thing as "equivalent" headings in hgroup; instead the first heading is document order is the primary heading and all others headings in the hgroup after the first are considered subheadings

[19:23:35.0000] <MikeSmith>
not sure my assessment is correct but I am sure that Hixie can say :)

[19:24:11.0000] <MikeSmith>
Hixie: you might want to respond on https://github.com/whatwg/html/issues/115 when you have tiem

[19:25:46.0000] <MikeSmith>
I think if the OP wants the semantic of "equivalent headings", then the way to get that is to not use hgroup at all but just put the headings one after another without any wrapper around them being needed

[19:27:08.0000] <MikeSmith>
> However, the only example utilizing the hgroup element in the spec shows how to create a subtitle, and the spec has this confusing text: "Other elements of heading content in the hgroup element indicate subheadings or subtitles". The quoted text indicates that the second h1 element might be considered a subtitle of the first h1 element.

[19:27:17.0000] <MikeSmith>
(from that issue)

[19:29:38.0000] <MikeSmith>
OP needs to s/might be considered/is considered/ in that last sentence

[19:29:58.0000] <MikeSmith>
That text in the spec doesn't seem confusing to me at all. It means exactly what it says. I think maybe the OP just wants it to mean something other than what it does mean.

[21:35:17.0000] <annevk>
rbyers: IRC can work, though our timezones are a bit off I think

[22:11:53.0000] <SimonSapin>
TabAtkins: zewt: something something xml document vs html document something

[22:23:27.0000] <SimonSapin>
zewt: you probably want CSSSelector(…, translator='html')

[22:23:30.0000] <SimonSapin>
the default is xml

[22:49:55.0000] <zewt>
well that's pretty bogus

[23:02:22.0000] <JakeA>
wanderview_pto: https://wiki-offline.JakeArchibald.com

[23:02:36.0000] <JakeA>
Ugh, without the caps

[23:24:58.0000] <JakeA>
annevk: I had a think about the CORS thing recently too. The closest I got is opaqueResponse.unlock(md5hash) - where you'd get the hash from another server, and if it matches the content, you can assume it's publically visible … but yeah, the hash could be guessable, and if the server output contains response time or time, it won't match etc etc

[23:33:02.0000] <annevk>
JakeA: yeah, that's not secure

[23:33:12.0000] <annevk>
JakeA: note that this is why integrity="" requires CORS

[23:34:33.0000] <JakeA>
Ah, of course

[23:37:59.0000] <annevk>
zcorpan: hey, so it seems we can start publishing WebVTT

[23:38:19.0000] <annevk>
zcorpan: is webvtt.html going to remain DirectoryIndex?

[23:38:29.0000] <zcorpan>
annevk: great. i'm in the process of bikeshedding it. yeah

[23:38:46.0000] <annevk>
cool

[23:39:33.0000] <Domenic>
Hmm maybe we should blog post the move to whatwg/html now that it's been such a success

[23:39:46.0000] <Domenic>
(And, we should blog post webvtt. And media session?!)

[23:48:16.0000] <MikeSmith>
Domenic: for HTML would we want to wait til the repo-chooser patch is merged

[23:48:36.0000] <Domenic>
MikeSmith: ah, I knew there was something I wanted to do tonight before going to sleep.

[23:48:47.0000] <MikeSmith>
heh

[23:50:21.0000] <MikeSmith>
we should also make sure annevk and philipj are OK with behavior of depth=1. I know they weren't super thrilled about that but I think it's still better than making somebody wait 10 minutes to pull the whole revision history

[23:51:27.0000] <MikeSmith>
Domenic: oh, I think also we should add one more refinement, which is: you should be able to just specify the path to your existing repo (if any) as an argument to the build script

[23:51:54.0000] <MikeSmith>
./build.sh /opt/workspace/html/source

[23:51:55.0000] <Domenic>
MikeSmith: instead of just doing HTML_SOURCE=blah ./build.sh? seems OK I guess.

[23:51:58.0000] <MikeSmith>
yeah

[23:52:05.0000] <annevk>
MikeSmith: can we make the build script remember the path?

[23:52:46.0000] <MikeSmith>
Domenic: OK will add that the branch after your review of what I got there now

[23:53:21.0000] <MikeSmith>
annevk: yeah, by setting HTML_SOURCE in your environment; e.g., in your .bashrc

[23:53:36.0000] <MikeSmith>
the build script doesn't keep state itself

[23:53:56.0000] <MikeSmith>
we could have it work from a .config file as you proposed before

[23:54:08.0000] <MikeSmith>
but that would be another PR

[23:54:10.0000] <MikeSmith>
I

[23:54:48.0000] <MikeSmith>
I would be happy to write up a patch for some .config thing if Domenic is also warm to that idea

[23:55:40.0000] <Domenic>
Hmm yeah maybe that is more user friendly than environment variables...

[23:55:51.0000] <zcorpan>
annevk: do you know what the bikeshed-correct way is to xref a global attribute? title, class...

[23:58:07.0000] <annevk>
zcorpan: there's quite a few ways unfortunately, if Shepherd indexed the correct term from HTML it could be as simple as <a spec=html>term</a>, if not, you need to create a local xref database in a <pre> element

[23:58:11.0000] <annevk>
zcorpan: DOM has one of those

[23:58:39.0000] <annevk>
zcorpan: okay, so currently WebVTT doesn't render due to respec being in a folder, I guess I can figure out if we can fix that somehow

[23:59:14.0000] <zcorpan>
ignore respec, i'm done bikeshedding soon

[23:59:30.0000] <annevk>
okay, then I'll leave the setup as is

[23:59:37.0000] <annevk>
it syncs all the root files

[23:59:52.0000] <zcorpan>
excellent, thanks

[00:05:49.0000] <MikeSmith>
Domenic: yeah I guess the more-typical thing is to have a .config.default (or whatever) checked into the repo, with instructions to copy it to .config and modify it

[00:06:46.0000] <Domenic>
yeah that seems reasonable

[00:11:58.0000] <annevk>
JakeA: there's quite a few folks at Mozilla that think service workers is not ready for CR, it's apparently not just me

[00:12:28.0000] <annevk>
JakeA: I don't really care since I think TR/ publication is rather meaningless, but where would we best discuss this?

[00:13:36.0000] <JakeA>
annevk: I agree on the meaningless bit. Could discuss on github or hold until TPAC?

[00:15:59.0000] <Domenic>
it seems reasonable to get all the people that care about CR in a room and let them talk to each other and not impact the people doing work.

[00:16:14.0000] <Domenic>
whether that room is a GitHub thread or a TPAC room, dunno.

[00:19:36.0000] <annevk>
JakeA: thanks, suggested that to them

[00:43:43.0000] <mkwst>
annevk: When you have a few minutes, could we poke at the HTTPS state thing again?

[00:44:26.0000] <mkwst>
annevk: (https://github.com/whatwg/html/pull/178)

[00:48:14.0000] <annevk>
mkwst: okay, so the issue is figuring out where Window is created

[00:49:46.0000] <mkwst>
annevk: Step 1 of "Initialising a new Document object"

[00:52:45.0000] <annevk>
mkwst: so I think what I would find acceptable for now is to have a new step 2 there that sets window's HTTPS state to resource's HTTPS state

[00:53:08.0000] <annevk>
mkwst: that's not ideal, but hopefully suffices for now

[00:53:16.0000] <annevk>
mkwst: I have some other quibbles too though

[00:53:24.0000] <annevk>
mkwst: should I make the nits on GitHub?

[00:53:54.0000] <mkwst>
Probably simpler to follow, but I'll take feedback however you like. :)

[00:55:03.0000] <mkwst>
The patch at https://github.com/whatwg/html/pull/178 adds exactly the step 2 I think you want. Line 82235.

[01:05:02.0000] <annevk>
Added comments

[01:05:09.0000] <annevk>
We really need an OmniGlobal mixin

[01:05:46.0000] <annevk>
Defining distinct slots for Worker and Document seems unnecessary

[01:05:54.0000] <annevk>
Anyway, that can be future cleanup

[01:09:49.0000] <zcorpan>
https://github.com/whatwg/webvtt/pull/213

[01:15:39.0000] <annevk>
zcorpan: as part of that PR you should probably also remove all the old stuff

[01:16:04.0000] <zcorpan>
hmm yes

[01:20:51.0000] <philipj>
MikeSmith: where do you want depth=1? if it's just in some script to get started, it doesn't matter to me, I know how to get the full history

[01:24:38.0000] <MikeSmith>
philipj: yeah just in the script to get started, and only if somebody doesn't have an existing clone they want to point the build to

[01:32:25.0000] <philipj>
MikeSmith: wfm

[01:33:34.0000] <zcorpan>
annevk: done

[01:53:58.0000] <mkwst>
annevk: Thanks. I poked at the PR to add the `about:srcdoc` handling. If you know of other places I should poke at, I'm happy to. Otherwise, I'll squash the patch if you're happy with the changes.

[01:55:23.0000] <annevk>
mkwst: search for an overridden reload</dfn>

[01:55:29.0000] <annevk>
mkwst: "an overridden reload</dfn>"

[01:55:52.0000] <annevk>
mkwst: I think that's the only two plus history traversal, but history traversal is still somewhat magic

[01:57:26.0000] <mkwst>
annevk: What causes an overridden reload? Is it safe to keep the HTTPS state of the document that's being navigated, or could this be called from a distinct browsing context?

[01:58:04.0000] <mkwst>
Ah, `document.open` and `document.write`. Ugh.

[01:58:15.0000] <mkwst>
Can we accidentally remove those from the platform? :)

[01:59:10.0000] <MikeSmith>
philipj: ok

[02:01:13.0000] <annevk>
mkwst: sounds like an excellent plan to get rid of some of that Chrome market share

[02:01:27.0000] <annevk>
mkwst: and also some Google ads, I'm told

[02:02:00.0000] <mkwst>
Yup. That's my job. Deprecate stuff that people use wildly in the hopes that they all go use Firefox instead.

[02:02:11.0000] <mkwst>
Your problem now, suckers!

[02:02:30.0000] <caitp>
don't get rid of document.write :(

[02:02:47.0000] <mkwst>
Ok. Poked at overridden reload in the patch as well.

[02:02:55.0000] <annevk>
caitp: seems unrealistic

[02:03:33.0000] <caitp>
the world needs document.write to make all of my stupid sites like http://caitp.github.io/commandments/ possible without writing a ton of markup

[02:03:49.0000] <caitp>
i know it wasn't serious :p

[02:04:53.0000] <annevk>
mkwst: could you add "new" before response in the about:srcdoc bit, okay if you don't want to

[02:06:04.0000] <mkwst>
annevk: Drive-by cleanup is fine with me. Done.

[02:06:34.0000] <annevk>
mkwst: HTTPS State -> HTTPS state

[02:07:52.0000] <mkwst>
annevk: Yeah, I wasn't very consistent, was I?

[02:07:54.0000] <mkwst>
Done.

[02:09:00.0000] <annevk>
mkwst: looks fine for rebase/squash

[02:09:46.0000] <mkwst>
/me squishes

[02:31:42.0000] <mkwst>
annevk: So, with that merged, what other "cards" do I need to put into place to make you happy with https://w3c.github.io/webappsec/specs/powerfulfeatures/ ? :)

[02:33:18.0000] <annevk>
mkwst: so for that are we going to change the way a SharedWorker is selected?

[02:34:52.0000] <annevk>
mkwst: is there any reason secure context flag needs to be set and cannot just be a "Secure Context" algorithm on environment settings objects that returns the results of these steps?

[02:35:50.0000] <mkwst>
annevk: I think we decided to set a flag on the Shared Worker in order to determine whether to allow connection from a particular context.

[02:36:13.0000] <mkwst>
annevk: If we have that flag, it made sense to me to just rewrite the algorithm in terms of flags everywhere.

[02:36:30.0000] <mkwst>
annevk: There's no reason to walk the ancestor tree every time; it's not changing.

[02:37:05.0000] <annevk>
mkwst: well then it can be a lazy getter just like the other bits that already exist on environment settings objects

[02:37:36.0000] <annevk>
mkwst: an environment settings object is currently just a collection of algorithms, it doesn't carry state

[02:39:25.0000] <annevk>
mkwst: anyway, most seems fine other apart from these editorial quibbles

[02:39:32.0000] <annevk>
mkwst: would be great to have the worker changes upstreamed too

[02:40:08.0000] <annevk>
mkwst: is the note about service workers correct?

[02:40:19.0000] <mkwst>
annevk: Yup. Will upstream once we're agreeing on the changes.

[02:40:41.0000] <annevk>
mkwst: I always thought http://example.com/ could embed https://videoservice.com/ and videoservice.com would have its service worker (if installed prior)

[02:40:58.0000] <annevk>
mkwst: if not that seems better though

[02:41:34.0000] <mkwst>
annevk: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#secure-context

[02:41:51.0000] <mkwst>
annevk: "... and the controlled service worker clients should also be secure contexts"

[02:41:59.0000] <mkwst>
annevk: no idea if that's what's implemented.

[02:42:07.0000] <annevk>
mkwst: ok

[02:42:15.0000] <annevk>
mkwst: "secure document" seems like an unused term

[02:43:43.0000] <mkwst>
annevk: Yeah. It's there as shorthand for other specs. *shrug* Dropping it wouldn't hurt, I suppose, but keeping it might make someone's life ever so slightly simpler.

[02:44:46.0000] <annevk>
mkwst: seems better if everyone used setting objects

[02:44:49.0000] <annevk>
but okay

[02:45:03.0000] <mkwst>
*shrug* Then I can drop it and "secure worker". Easy.

[02:45:06.0000] <annevk>
well, I'm not a fan of settings objects either, but for now...

[02:45:15.0000] <mkwst>
What would you like us to use instead?

[02:45:17.0000] <annevk>
hopefully they can be merged with globals

[02:45:35.0000] <annevk>
I opened an issue against HTML to reduce the number of concepts floating around

[02:45:37.0000] <mkwst>
Hrm. How do you explain folks with JavaScript disables?

[02:46:18.0000] <annevk>
mkwst: that there's still a global I suppose, just that script doesn't execute

[02:46:35.0000] <mkwst>
Interesting.

[02:46:43.0000] <annevk>
mkwst: many algorithms in the spec grab things from global objects already

[02:47:04.0000] <mkwst>
*shrug* Probably. You're more familiar with it than I am.

[02:51:44.0000] <mkwst>
annevk: Ok. So, when you say that the concept can be a lazy getter on the settings object, what do you mean? We need to store a bit of some sort for Shared Workers at creation time.

[02:52:16.0000] <mkwst>
annevk: I'm currently setting a flag on the settings object in "set up a worker environement settings object". I suppose I could set a flag on the global instead.

[02:52:19.0000] <annevk>
mkwst: ah, above you said it wasn't changing

[02:53:00.0000] <mkwst>
It doesn't change after it's set. But it needs to be set. :)

[02:53:37.0000] <mkwst>
That is, for documents, we can just walk the tree whenever, easy. The flag is an optimization for those cases, but not necessary.

[02:53:42.0000] <mkwst>
For dedicated workers, same thing.

[02:54:01.0000] <mkwst>
For Shared Workers, we can't walk the tree whenever, we need to walk it at creation time and store the result somewhere.

[02:54:23.0000] <annevk>
It seems even for shared workers you could first lookup by constructor url/name, and then see if secure context returns the same thing in both places

[02:55:08.0000] <annevk>
E.g., is there a SharedWorkerGlobalScope whose constructor url is url, name is name, and secure context is secure context...

[02:56:00.0000] <mkwst>
Hrm. Ok. That could work.

[02:56:18.0000] <mkwst>
It seems more roundabout than setting a bit on the context.

[02:56:42.0000] <mkwst>
But I think you're right, it would be equivalent behavior.

[03:32:07.0000] <mkwst>
annevk: WDYT about https://github.com/w3c/webappsec/commit/90210b3ae0e70408cb6a8640d3a647f610630502?

[03:32:29.0000] <mkwst>
simpler to read at https://w3c.github.io/webappsec/specs/powerfulfeatures/#settings-object

[03:56:22.0000] <annevk>
mkwst: looks good

[03:56:28.0000] <annevk>
mkwst: 'This covers scenarios such as &lt;iframe sandbox src="http://localhost/"&gt;.' looks wrong

[03:57:04.0000] <mkwst>
Hrm. I'm surprised bikeshed escaped those.

[03:58:31.0000] <mkwst>
thanks for catching that.

[06:36:54.0000] <rbyers>
annevk: Timezone offset isn't that bad (as it is for europe<->california) - I'm UTC-4

[06:37:38.0000] <annevk>
rbyers: morning

[06:37:57.0000] <rbyers>
annevk: Morning.  Have a few minutes to chat?

[06:38:12.0000] <annevk>
rbyers: not in theory, but in practice it seems like it

[06:39:12.0000] <rbyers>
annevk: Heh, ok.  Let's try stepping back for a second, ignore EventListenerOptions....

[06:40:08.0000] <rbyers>
.. Today afaik all browsers observe touch/wheel listeners in order to get an important scroll performance optimization when handlers aren't present (or aren't present at a particular point).

[06:40:36.0000] <rbyers>
.. You can think of it as the UA making some events uncancelable if it sees there are no listener that can possibly cancel it.

[06:41:33.0000] <rbyers>
.. It's not clear to me if that technically violates the spec.  On the one hand the UAs would argue its an impl detail, but on the other it has major impact on performance and so is something UAs really need to be interoperable around and developers need to understand...

[06:42:36.0000] <rbyers>
.. If we take for granted that UAs are not going to give up this optimization (they're not), then should the spec say something about it?

[06:42:45.0000] <annevk>
rbyers: yeah, generally we've counted that as not violating

[06:42:53.0000] <annevk>
rbyers: UAs do the same with certain sensor APIs

[06:43:04.0000] <annevk>
rbyers: although I do find it sketchy

[06:43:07.0000] <annevk>
rbyers: oh, back in a bit

[06:43:19.0000] <rbyers>
annevk: Ok

[06:46:19.0000] <schalkneethling>
hey there all

[06:46:46.0000] <schalkneethling>
was wondering, is the mediagroup attribute on the video element currently implemented in a browser?

[06:47:10.0000] <schalkneethling>
it might just be that I do not understand the usage of the attribute but, it seems it is not yet implemented

[06:47:49.0000] <schalkneethling>
so, what the spec seems to suggest is that if two media elements share a mediagroup attribute with the same name, they will be linked by the user agent and share the same media controller

[06:48:01.0000] <schalkneethling>
I assume from a UI persepctive this means the controls

[06:48:10.0000] <schalkneethling>
but perhaps I misunderstand

[06:48:42.0000] <schalkneethling>
also, if the two media resources are the same, they will use the same network request irrespective of how many times it is embedded in the same document

[06:57:48.0000] <roc>
schalkneethling: AFAIK that feature is going nowhere

[07:03:52.0000] <annevk>
rbyers: so, given that Hixie seems okay I guess I can be too

[07:04:15.0000] <annevk>
rbyers: I was mostly trying to hold the fort

[07:05:17.0000] <rbyers>
annevk: Cool.  Yeah, understood - but honestly I think we can use this to make the situation you're concerned with BETTER.  I'm with you here!  But it does complicate the spec, but IMHO that mainly comes from trying to better reflect the actual implementations.

[07:05:55.0000] <rbyers>
annevk: Eg. should we add some text saying that UAs can use listener presence only in specific ways?

[07:06:25.0000] <rbyers>
.. like to avoid work necessary to generate the events (sensors) or to make events uncanceable?

[07:07:25.0000] <rbyers>
.. we could even specify that UAs cannot use the presence of any mayCancel=false listeners to cause any observable change in behavior (including non-trivial performance differences).

[07:07:28.0000] <annevk>
rbyers: I think we should only allow observability outside the perf realm if there's a standard for it (e.g., touch events)

[07:08:07.0000] <annevk>
rbyers: and I think we should try to caution any new features to be build that way (and if someone still feels compelled, they should contact public-script-coord or some other review list)

[07:08:26.0000] <annevk>
rbyers: we should probably also add the example Hixie gave as to why observability is bad

[07:08:38.0000] <rbyers>
annevk: That makes sense.

[07:09:16.0000] <annevk>
roc: should it be removed from the spec?

[07:09:27.0000] <rbyers>
annevk: Any suggestion for where this sort of text belongs (and what's normative)?  Or should I try to come up with something then we can discuss concretely on the PR.

[07:09:53.0000] <roc>
annevk: maybe. I think Apple may have tried to implement it at some point.

[07:10:13.0000] <roc>
I have seen absolutely zero interest in us implementing it, from inside or outside

[07:10:53.0000] <annevk>
rbyers: I think we should add a section after Interface EventTarget called "Observing event listeners" that spells this out

[07:11:03.0000] <annevk>
rbyers: since it's mostly advice and examples it would be non-normative

[07:11:26.0000] <annevk>
rbyers: similar to "Action versus occurrence" I suppose

[07:11:30.0000] <rbyers>
annevk: Sounds good, I'll take a crack at that.

[07:11:58.0000] <annevk>
rbyers: my other concerns are the defaulting of the dictionary member and its name

[07:12:08.0000] <rbyers>
annevk: Right, was just going to ask about https://github.com/RByers/EventListenerOptions/issues/17#issuecomment-142341211

[07:12:14.0000] <annevk>
rbyers: but I haven't developed answers yet

[07:12:55.0000] <rbyers>
annevk: I can just try flipping it to 'disableCancel' or some such and see what you think - I think the spec will read much better that way.

[07:13:32.0000] <annevk>
I vaguely remember me giving a single word suggestion somewhere

[07:13:41.0000] <rbyers>
.. no practical downside to inverting that I can see.

[07:13:47.0000] <rbyers>
Oh?  I don't recall that.

[07:15:14.0000] <annevk>
rbyers: https://github.com/RByers/EventListenerOptions/issues/22#issuecomment-126031470

[07:15:27.0000] <annevk>
rbyers: although Domenic didn't like my defaulting strategy

[07:16:07.0000] <rbyers>
annevk: Ahh 'passive' works for me.  I think we can simplify the default strategy.

[07:16:29.0000] <annevk>
rbyers: yeah if we just default to false, passive works well

[07:23:34.0000] <annevk>
rbyers: another thought

[07:23:38.0000] <annevk>
rbyers: we call it "fast"

[07:23:50.0000] <annevk>
rbyers: defaults to false

[07:24:21.0000] <rbyers>
annevk: Hah, I kind of like that.  Pretty vague though and in many cases (most types of events) it's really a lie.

[07:24:30.0000] <annevk>
rbyers: bad default is due to bad legacy, but everyone wants fast so they'll deal

[07:24:53.0000] <rbyers>
I'll add it to the list (https://github.com/RByers/EventListenerOptions/issues/17#issuecomment-142341211)

[07:25:23.0000] <rbyers>
FWIW it's also "fast" to have a touch/wheel listener which always calls preventDefault (and so must NOT be passive).

[07:25:54.0000] <annevk>
fair enough

[07:25:55.0000] <rbyers>
Eg. it's not like it's bad for games/maps to let you do something else with touch/wheel other than scrolling.  So I feel like fast is a confusing over-simplification.

[07:29:19.0000] <schalkneethling>
thanks roc

[07:50:36.0000] <rbyers>
annevk: One other little editorial question: An EventListener is defined to be made up of some variables (https://dom.spec.whatwg.org/#concept-event-listener).  Do you prefer keeping these to be simple types (i.e. "capture" and "passive" boolean variables), or is it better to talk of there being an "options" variable of type EventListenerOptions?

[07:50:56.0000] <rbyers>
.. I think the latter will simplify the text slightly (can just say "same options" rather than "same capture and passive")

[07:51:11.0000] <rbyers>
.. But not sure IDL dictionary types are OK in this context.

[07:53:01.0000] <annevk>
rbyers: since you'd have to define what "same options" means I don't think it would actually end up being shorter

[07:53:51.0000] <rbyers>
yeah, ok- I guess that's not a given

[07:54:12.0000] <rbyers>
annevk: Also, any preference for the argument name - I had "optionsOrCapture" which is pretty verbose, perhaps just "options" is good enough?

[07:56:28.0000] <annevk>
rbyers: yeah, options or init is fine

[07:56:50.0000] <rbyers>
ok, thanks

[10:23:08.0000] <MikeSmith>
botie, inform zcorpan lemme know when you have a few minutes to catch up about wbvtt stuff

[10:23:08.0000] <botie>
will do

[10:24:40.0000] <annevk>
rbyers: if preventDefault() doesn't throw, the canceled flag would be sufficient in principle, no?

[10:24:50.0000] <annevk>
rbyers: that is, no need for the passive flag

[10:25:33.0000] <rbyers>
annevk: Sorry, I don't follow.  How would the canceled flag be sufficient?

[10:25:46.0000] <rbyers>
Something needs to track whether we're in the context of a passive listener or not...

[10:26:02.0000] <rbyers>
And I don't think we can re-use the canceled flag for that because we don't want to change Event.defaultPrevented

[10:26:27.0000] <annevk>
rbyers: oh, I figured the model would be that only if all listeners are passive you'd get a passive event

[10:26:52.0000] <annevk>
rbyers: I guess you might still want to enforce things per-listener to assist developers

[10:26:59.0000] <annevk>
rbyers: makes sense

[10:27:37.0000] <rbyers>
annevk: Exactly, otherwise it can be very brittle for libraries to try to adopt this incrementally.

[10:28:13.0000] <rbyers>
This is basically the discussion here: https://github.com/RByers/EventListenerOptions/issues/2

[10:28:27.0000] <annevk>
rbyers: I think we might want to expose that the event changed fundamentally too, but perhaps the flip from cancelable to non-cancelable is sufficient

[10:29:22.0000] <MikeSmith>
roc: I thought mediagroup support was largely motivated by accessibility needs (to be able to play synchronized secondary descriptive audio or sign-language streams)

[10:29:33.0000] <rbyers>
annevk: You mean when all listeners are passive?  Right - the key thing the dev cares about is whether the event is cancelable.

[10:30:03.0000] <rbyers>
annevk: Presumably we don't need to indicate that the event is "fundamentally" different somehow just because one (of several) listeners is passive.  That doesn't change the event.

[10:30:15.0000] <annevk>
rbyers: yeah, when some spec decides to dispatch a different kind of event from the normal one, effectively

[10:30:27.0000] <annevk>
rbyers: agreed

[10:30:53.0000] <annevk>
rbyers: that's the distinction I was trying to make sense of

[10:30:58.0000] <rbyers>
annevk: Right.  One question we debates was whether we should say that ALL events behave that way (sending uncancelable when all listeners are passive) or leave it up to the specific event type to define.  We agreed with smaug on the latter I believe.

[10:30:59.0000] <annevk>
rbyers: different listeners vs different event

[10:31:37.0000] <rbyers>
annevk: Right, that's confusing but an important distinction.  If you can think of any way for me to clarify in the spec text let me know.  Otherwise I'll just try to summarize in my explainer doc.

[10:31:47.0000] <annevk>
rbyers: the latter makes sense to me too, due to the observable thing still being suboptimal

[10:32:51.0000] <rbyers>
annevk: Yep, I'm happy with that.  I'll try to ellaborate a bit on this in the new observability section I'm adding.

[10:34:39.0000] <annevk>
This might affect the service workers discussions too with regards to "fetch" listeners being observable or not

[10:36:13.0000] <rbyers>
annevk: Oh interesting, I was unaware of that discussion.

[10:49:37.0000] <botie>
zcorpan, at 2015-09-24 17:23 UTC, MikeSmith said: lemme know when you have a few minutes to catch up about wbvtt stuff

[13:23:18.0000] <JonathanNeal>
I get the double dash for custom media queries, custom selectors, and custom variables, but I was wondering if someone could explain to me why the var() is also needed?

[13:24:00.0000] <MikeSmith>
JonathanNeal: I bet TabAtkins could

[13:57:15.0000] <JonathanNeal>
Probably the most aggressive tweet in my entire career. https://twitter.com/jon_neal/status/647152310813073408 on the subject of obsfucating all the codes to get past ad block filters.

[14:02:45.0000] <MikeSmith>
I don't blame them for trying

[14:03:09.0000] <MikeSmith>
in the end it all just helps to make the ad blockers even smarter and better

[14:03:22.0000] <MikeSmith>
so it's all win for us

[14:03:59.0000] <MikeSmith>
whatever battle they think they're fighting, they've already lost

[14:21:16.0000] <TabAtkins>
JonathanNeal: Because it make the context clear.

[14:23:28.0000] <JonathanNeal>
What did you find too ambiguis about -- sans the var in scenarios where there is not a fallback?

[14:23:39.0000] <JonathanNeal>
s/ambiguis/ambiguous

[14:34:59.0000] <TabAtkins>
I found that the bare keyword didn't feel as visible and obvious as the var() function did.

[14:35:51.0000] <TabAtkins>
Also, you need the var() function anyway (to provide defaults, at least, and more in the future), and having two syntaxes for the same thing ("color: --foo;" if you didn't need any extra functionality, "color: var(--foo, blue);" if you did) increases complexity.

[15:26:05.0000] <JonathanNeal>
Okay, the increases complexity part was the only thing that came to mind for me, due to the manner in which it takes a default (what I was calling a fallback).

[15:27:28.0000] <JonathanNeal>
I guess I’m glad custom media and custom properties don’t take fallbacks like that. They rely and fallback based on inheritence only, I suspect?

[15:27:40.0000] <JonathanNeal>
s/custom properties/custom selectors

[15:28:07.0000] <MikeSmith>
annevk: http://stackoverflow.com/questions/32771832/securing-cors-is-the-a-security-scheme-with-cookies

[15:36:56.0000] <TabAtkins>
JonathanNeal: custom media/etc don't have any other options to deal with, and are immediately clear from context.

[16:14:08.0000] <roc>
This paper is very interesting: https://fbcdn-dragon-a.akamaihd.net/hphotos-ak-xap1/t39.2365-6/10935986_985284008163608_743666691_n/Moving_Fast_with_Software_Verification.pdf

[16:14:16.0000] <roc>
one of the interesting parts is the beginning where they contrast native mobile app development with Web development. In particular, that on the Web you control which version of your code users are running, and with native apps you don't. Which makes a big difference.

[16:40:42.0000] <roc>
cool use of SVG: http://unifiedpatents.com/1st-half-2015-patent-dispute-report/

[16:51:29.0000] <gavinc>
SVGs would be cooler if they were right

[16:51:52.0000] <gavinc>
Delaware had 946 patents cases not 249


2015-09-25
[19:06:23.0000] <JonathanNeal>
Hey, give or take 697.

[01:11:34.0000] <annevk>
Domenic: one more look? https://github.com/whatwg/html/pull/187

[01:18:08.0000] <annevk>
MikeSmith: attempted an answer of sorts

[01:25:02.0000] <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.

[01:26:04.0000] <Domenic>
annevk: I can't actually find the definition for #concept-WorkerGlobalScope-url ?

[01:26:47.0000] <annevk>
Domenic: directly below WorkerGlobalScope</dfn>

[01:27:02.0000] <annevk>
Domenic: "A WorkerGlobalScope object has an associated url (null or a URL). It is initially null."

[01:27:23.0000] <annevk>
Domenic: but the data-x stuff gets lowercased

[01:27:29.0000] <annevk>
Domenic: so #concept-workerglobalscope-url

[01:28:14.0000] <Domenic>
Ah OK

[01:29:46.0000] <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

[01:30:14.0000] <Domenic>
annevk: it seems better to me to follow CORS on all new things.

[01:30:22.0000] <Domenic>
<script type="module"> should mostly be used for inline anyway, IMO.

[01:30:32.0000] <Domenic>
But I guess the question recurs for absolute-URL `import`s

[01:30:38.0000] <annevk>
Domenic: yeah, I think we cannot not require CORS

[01:30:40.0000] <Domenic>
/me is in European timezone for a few days

[01:30:57.0000] <annevk>
Domenic: not sure what to default to though

[01:31:06.0000] <annevk>
Domenic: I guess "anonymous"

[01:42:12.0000] <Domenic>
Hmm I wonder if http://www.w3.org/TR/cors/ should go in https://wiki.whatwg.org/wiki/Fork_tracking ?

[01:42:48.0000] <annevk>
Domenic: s/the/this/ would no longer be consistent with the definition for self

[01:43:02.0000] <annevk>
Domenic: we really need an IDL-defined "this"

[01:43:11.0000] <annevk>
Domenic: yeah I guess it should

[01:43:21.0000] <annevk>
Domenic: that's been causing a ton of confusion

[01:43:38.0000] <annevk>
Domenic: I will add it

[01:43:44.0000] <Domenic>
annevk: acknowledged on s/the/this

[02:15:00.0000] <nox>
annevk: Talking about WebIDL, https://github.com/heycam/webidl/pull/58

[02:19:47.0000] <MikeSmith>
annevk: thanks (for the SO answer)

[02:21:50.0000] <annevk>
nox: you want heycam|away

[02:28:57.0000] <annevk>
Okay shit, I accidentally force pushed html-build

[02:29:10.0000] <annevk>
Can someone undo?

[02:29:17.0000] <annevk>
And then enable protection for master?

[02:29:26.0000] <annevk>
MikeSmith: Domenic: ^^

[02:32:04.0000] <annevk>
MikeSmith: Domenic: unless there were commits after zcorpan's commit, nothing may have been damaged

[02:43:28.0000] <MikeSmith>
annevk: will take a look, and no worries, I'm sure we can unwind it if needed

[02:43:49.0000] <MikeSmith>
but yeah, will set up master-branch protection there right now

[02:44:16.0000] <MikeSmith>
btw is anything I wrote at http://stackoverflow.com/a/32769242/441757 not accurate?

[02:44:50.0000] <Domenic>
annevk: yeah can fix, although my Linux computer is back at the hotel so will be a few hours.

[02:45:05.0000] <MikeSmith>
(about non-localhost web apps being able to read from local  file:// URLs)

[02:45:17.0000] <annevk>
MikeSmith: Domenic: I'll just not touch anything there for now

[02:46:13.0000] <MikeSmith>
Domenic: I'll just wait for you to reset it, unless you want me to deal with it in the mean tiem

[02:46:54.0000] <Domenic>
MikeSmith: if you have the latest commits locally then go ahead.

[02:47:09.0000] <MikeSmith>
k looking now

[02:47:10.0000] <nox>
annevk: Yes, but as you say he is away. :)

[02:50:20.0000] <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

[02:50:40.0000] <MikeSmith>
so I'll go ahead and force-push from my clone

[02:50:51.0000] <Domenic>
Shouldn't need force, right?

[02:50:56.0000] <MikeSmith>
ah yeah

[02:51:28.0000] <Domenic>
But yeah I am 95% sure that was HEAD.

[02:51:41.0000] <MikeSmith>
yeah same here

[02:52:18.0000] <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

[02:52:30.0000] <MikeSmith>
I definitely didn't push to master myself since then

[02:53:52.0000] <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

[02:54:12.0000] <annevk>
MikeSmith: enable protection?

[02:54:49.0000] <MikeSmith>
yup, just did now

[02:55:02.0000] <MikeSmith>
so all is now right with the world again

[02:55:19.0000] <annevk>
sorry about that

[02:55:37.0000] <annevk>
glad things are still a bit distributed, even though GitHub is not

[02:55:54.0000] <MikeSmith>
yeah

[04:21:37.0000] <smaug____>
annevk: could "9.5.4 Broadcasting to many ports" be possibly removed from the spec

[04:23:40.0000] <smaug____>
/me files a bug

[04:39:42.0000] <MikeSmith>
fyi I just now added a deprecation warning to https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache

[04:40:08.0000] <MikeSmith>
I guess it should be added to all other MDN pages for appcache

[04:43:14.0000] <MikeSmith>
what's the release date for Firefox 42?

[04:43:26.0000] <MikeSmith>
beginning of November? middle?

[04:43:57.0000] <MikeSmith>
/me finds http://release.mozilla.org/planning/2015/01/13/release-schedule.html

[04:44:06.0000] <MikeSmith>
2015-11-03

[04:44:06.0000] <botie>
2001

[04:45:45.0000] <Ms2ger>
Thank you botie

[04:46:39.0000] <MikeSmith>
yeah I got no idea what "feature" of botie produced that, but I approve

[04:46:44.0000] <MikeSmith>
botie++

[04:47:12.0000] <smaug____>
https://wiki.mozilla.org/RapidRelease/Calendar

[04:48:14.0000] <MikeSmith>
/me looks

[04:50:05.0000] <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

[04:50:23.0000] <Domenic>
hahaha

[04:50:33.0000] <MikeSmith>
thanks smaug____

[04:50:35.0000] <Domenic>
botie is so endearingly dumb

[04:50:45.0000] <MikeSmith>
hah

[04:50:47.0000] <MikeSmith>
yeah

[04:52:05.0000] <zcorpan>
1-2

[04:52:20.0000] <zcorpan>
:-|

[05:01:55.0000] <MikeSmith>
zcorpan: you gotta tell it the right way :p

[05:02:24.0000] <zcorpan>
2015-11-2500

[05:02:25.0000] <botie>
-496

[05:04:00.0000] <zcorpan>
2015-11-66000

[05:04:00.0000] <botie>
-63996

[05:04:11.0000] <Domenic>
=1-2

[05:04:16.0000] <Domenic>
1-2=?

[05:04:26.0000] <zcorpan>
2015-11-4294967296

[05:04:26.0000] <botie>
-4294965292

[05:04:36.0000] <Domenic>
uh oh

[05:05:17.0000] <zcorpan>
2015-2016-4294967296

[05:05:18.0000] <botie>
-4294967297

[05:07:26.0000] <Ms2ger>
Kiddos... :)

[05:08:16.0000] <zcorpan>
1-2-9007199254740992

[05:08:16.0000] <botie>
-9007199254740993

[05:08:22.0000] <zcorpan>
impressive

[05:08:40.0000] <zcorpan>
python?

[05:11:43.0000] <zcorpan>
next up, consume all for botie's RAM with a big number :-)

[05:12:36.0000] <Ms2ger>
Anyone harassing bots shall be punished :)

[05:17:11.0000] <zcorpan>
no chocolate? :-(

[05:21:45.0000] <Ms2ger>
TabAtkins, wanna define @import in terms of Fetch?

[06:21:13.0000] <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

[06:22:45.0000] <MikeSmith>
(in light of https://github.com/w3c/webappsec/pull/460 「SRI: remove "Fetch Modifications" section」)

[06:26:35.0000] <MikeSmith>
gsnedders: does html5lib work under Python 3?

[06:28:55.0000] <Ms2ger>
I think it should

[06:29:23.0000] <MikeSmith>
ok

[06:29:42.0000] <MikeSmith>
I figured it did but wasn't sure

[07:20:58.0000] <annevk>
MikeSmith: well, fetch() will remain working for SRI

[07:21:12.0000] <annevk>
MikeSmith: I guess the question is whether the MDN page should reflect the spec or the feature

[07:21:17.0000] <annevk>
MikeSmith: I'd think the latter, personally

[07:22:21.0000] <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

[07:22:35.0000] <MikeSmith>
and he's dropping it from the SRI spec for now

[07:22:41.0000] <MikeSmith>
that's what the PR does, right?

[07:22:57.0000] <annevk>
MikeSmith: no, the PR just reflects changes in Fetch

[07:23:06.0000] <MikeSmith>
oh ok

[07:23:12.0000] <annevk>
MikeSmith: integrity for fetch() is defined by Fetch

[07:23:18.0000] <MikeSmith>
ah yeah OK

[07:23:26.0000] <annevk>
MikeSmith: and we should define integrity for <link> and <script> in HTML, really

[07:23:39.0000] <MikeSmith>
yeah

[07:23:41.0000] <MikeSmith>
OK

[07:26:05.0000] <annevk>
smaug____: you know you can submit PRs, right? ;-)

[07:26:55.0000] <smaug____>
github...

[07:27:03.0000] <smaug____>
I could write a patch I guess

[07:27:06.0000] <annevk>
smaug____: it's a magical place

[07:27:14.0000] <smaug____>
/me wonders how to attach patches to github

[07:27:18.0000] <smaug____>
I guess it is somehow possible

[07:27:31.0000] <annevk>
smaug____: I'm happy to do it for you

[07:27:58.0000] <annevk>
smaug____: didn't realize you hadn't worked with PRs at all yet

[07:28:46.0000] <smaug____>
I'm very old school

[07:28:52.0000] <smaug____>
ancient beast

[07:29:18.0000] <annevk>
from a children's fairy tale, right?

[07:30:36.0000] <smaug____>
I don't count any Tolkien's Middle-earth related work as children's fairy tale, just fairy tale ;)

[07:31:06.0000] <annevk>
I suppose, I thought the Hobbit was meant for children, but it's entertaining either way

[07:32:12.0000] <smaug____>
(sure, it was was probably written for children, but sort of turned out to be also something else)

[07:34:54.0000] <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.

[07:35:20.0000] <annevk>
smaug____: not sure, I think baku has been fixing some of that stuff

[07:35:21.0000] <smaug____>
IMO the current setup is overengineered, but most probably too late to change

[07:35:32.0000] <smaug____>
yeah, baku implemented MessagePorts

[07:35:43.0000] <smaug____>
I'm thinking about the spec

[07:36:03.0000] <annevk>
smaug____: you mean we should just have had simple message passing and no channels and all that?

[07:36:13.0000] <smaug____>
because jesup was asking about making DataChannel transferable

[07:36:51.0000] <annevk>
cloneable or transferable?

[07:36:58.0000] <smaug____>
annevk: well, at least once a MessagePort is started, is there any good use case to transfer it?

[07:37:04.0000] <smaug____>
annevk: transferable

[07:37:22.0000] <annevk>
smaug____: I think Hixie had some use cases around services

[07:37:46.0000] <smaug____>
you'd get RTCDataChannel probably in the main thread and transfer it to some worker

[07:37:54.0000] <annevk>
smaug____: but it's been a while since I tried to look into that and it was probably too complicated for me anyway

[07:38:44.0000] <smaug____>
so I wonder if RTCDataChannel could actually have some tiny bit simpler setup

[07:38:56.0000] <smaug____>
oh well, I'll let jesup to sort this out

[07:47:11.0000] <TabAtkins>
Ms2ger: Yes I do.

[07:50:01.0000] <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. >_<

[08:34:16.0000] <aleray>
Hi, I have this piece of code using html5lib-python: http://dpaste.com/2WEDB88

[08:34:50.0000] <aleray>
do you know why I get `u'<p>Des outils sensibles'` instead of `u'<p>Des outils sensibles</p>'`

[08:34:56.0000] <aleray>
?

[08:41:14.0000] <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

[09:02:51.0000] <annevk>
JakeA: https://github.com/whatwg/fetch/issues/106#issuecomment-142218051

[09:39:00.0000] <annevk>
The WebSocket plot thickens

[09:39:23.0000] <Hixie>
lordy now what

[09:39:38.0000] <annevk>
Hixie: hey!

[09:40:12.0000] <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

[09:40:17.0000] <annevk>
Hixie: https://github.com/whatwg/html/issues/180 has ramblings

[09:41:14.0000] <Hixie>
websocket is unaffected by hsts in theory. it's not http.

[09:41:40.0000] <annevk>
In practice it seems it kinda is

[09:41:58.0000] <annevk>
I very much expect that in browsers they go in the same Fetch pipeline as everything else

[09:42:12.0000] <Hixie>
figures

[10:24:50.0000] <Hixie>
abarth: https://github.com/flutter/engine/pull/1344

[10:52:20.0000] <abarth>
Hixie: https://github.com/flutter/engine/pull/1345 <--- moar tests

[11:28:25.0000] <abarth>
Hixie: https://github.com/flutter/engine/pull/1346 <---  MOAR tests

[11:29:54.0000] <terinjokes>
does SRI make sense for scripts being served from your own domain (with TLS)?

[11:30:07.0000] <terinjokes>
seems like all the example are for loading content from CDNs

[13:03:28.0000] <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)

[13:05:08.0000] <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

[13:05:56.0000] <MikeSmith>
and we want to make sure versions are accidentally getting overwritten

[13:07:34.0000] <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

[13:08:33.0000] <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.

[13:38:47.0000] <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

[13:42:35.0000] <MikeSmith>
terinjokes: sounds workable

[13:42:45.0000] <terinjokes>
gracias

[13:43:09.0000] <terinjokes>
no plans to allow other users to modify the page, but who knows

[13:43:23.0000] <terinjokes>
ensuring we're delivering the right version is a nice addition though

[13:52:07.0000] <SimonSapin>
Do browsers run html5lib tests?

[13:55:55.0000] <MikeSmith>
SimonSapin: I believe Mozilla CI does, right?

[13:56:02.0000] <MikeSmith>
via wpt

[13:56:36.0000] <MikeSmith>
because they are incorporated into the wpt repo

[13:57:52.0000] <MikeSmith>
SimonSapin: https://github.com/w3c/web-platform-tests/tree/master/html/syntax/parsing

[13:58:15.0000] <MikeSmith>
the htmllib_*html files

[14:07:41.0000] <SimonSapin>
MikeSmith: I’m trying to get the history right to explain html5lib vs libxml2 (lxml.html) in a blog post

[14:07:47.0000] <SimonSapin>
also, https://github.com/SimonSapin/html5ever-python :)

[14:09:19.0000] <SimonSapin>
MikeSmith: is it fair to call html5lib a reference implementation developed alongside the HTML parsing spec?

[14:10:24.0000] <MikeSmith>
yes

[14:10:32.0000] <MikeSmith>
it is fair to say that

[14:10:44.0000] <MikeSmith>
it was the first implementation of the parsing algorithm

[14:11:19.0000] <MikeSmith>
ah nice to have the Python bindings for html5ever

[14:11:45.0000] <MikeSmith>
SimonSapin: and yeah it absolutely was developed alongside the parsing spec

[14:11:57.0000] <MikeSmith>
jgraham and gsnedders could give you more of the history

[16:17:47.0000] <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.

[16:18:08.0000] <SimonSapin>
fair enough


2015-09-26
[03:00:20.0000] <qq[IrcCity]>
hello.  where can I find people who care about bugs in processing “text/plain” by major modern browsers?  more details here http://www.superstructure.info/browser/compromised/toxic-sniffing.html (the story is only partially written, but enough to see bugs).

[03:07:25.0000] <annevk>
qq[IrcCity]: "bugs"

[03:07:35.0000] <annevk>
qq[IrcCity]: see https://mimesniff.spec.whatwg.org/

[03:09:17.0000] <annevk>
qq[IrcCity]: if your problem is with BOM being more important than other encoding declarations, that's https://encoding.spec.whatwg.org/

[03:09:21.0000] <annevk>
qq[IrcCity]: also not considered a bug

[03:15:38.0000] <qq[IrcCity]>
annevk: a text wall too high; didn’t find anyting relevant to my case but mentioning of one https://mimesniff.spec.whatwg.org/#no-sniff-flag but without much detail.

[03:15:39.0000] <qq[IrcCity]>
 could you give a link to provisions that are relevant to “text/plain”?

[03:16:16.0000] <annevk>
qq[IrcCity]: it's very much unclear what "processing bug" you're talking about so I don't know

[03:16:30.0000] <annevk>
qq[IrcCity]: if it's indeed mostly about encodings, I recommend reading the Encoding Standard

[03:16:37.0000] <annevk>
qq[IrcCity]: you shouldn't be using non-utf-8 encodings anyway

[03:16:50.0000] <qq[IrcCity]>
damn.   who approved it?

[03:16:51.0000] <annevk>
qq[IrcCity]: and BOM trumps Content-Type

[03:17:19.0000] <annevk>
qq[IrcCity]: not sure what you mean

[03:17:35.0000] <qq[IrcCity]>
which standard-making body declared “you shouldn't be using non-utf-8 encodings anyway”?

[03:18:07.0000] <annevk>
qq[IrcCity]: WHATWG, and I guess W3C did too since they copied it over

[03:20:45.0000] <qq[IrcCity]>
annevk: W3C standard of HTML5 doesn’t contain such rubbish.   it ony specified that if the document is seemingly Unicode (isn’t encoded in an octet-oriented code page), then BOM takes precedence.

[03:21:43.0000] <annevk>
qq[IrcCity]: while out of date and a poor reference, http://www.w3.org/TR/encoding/ most certainly has the same requirement as https://encoding.spec.whatwg.org/ with regards to utf-8

[03:22:26.0000] <annevk>
qq[IrcCity]: also, http://www.w3.org/TR/html5/references.html#refsENCODING

[03:22:51.0000] <annevk>
qq[IrcCity]: anyway, I wouldn't recommend reading W3C copies, they're not what's being implemented

[03:24:41.0000] <qq[IrcCity]>
http://www.w3.org/TR/encoding/ doesn’t state anything is deprecated, restricted to certain circumstances, or so.    all encodings are, theoretically, permitted.

[03:25:21.0000] <annevk>
qq[IrcCity]: *sigh*

[03:25:25.0000] <annevk>
qq[IrcCity]: 'Authors must use the utf-8 encoding and must use the ASCII case-insensitive "utf-8" label to identify it.'

[03:26:23.0000] <qq[IrcCity]>
again, HTML5 is about “text/html”.  annevk, do you understand the word “text/plain”?

[03:26:39.0000] <annevk>
qq[IrcCity]: HTML defines how text/plain works

[03:26:55.0000] <annevk>
qq[IrcCity]: and text/plain is not a word

[03:27:08.0000] <qq[IrcCity]>
RoTFL.   these are different media types.

[03:27:54.0000] <annevk>
qq[IrcCity]: sure, but it's rendered using the HTML parser, see "Page load processing model for text files"

[03:28:01.0000] <annevk>
qq[IrcCity]: in the HTML standard

[03:28:27.0000] <qq[IrcCity]>
annevk, I read in HTML5 about parser.

[03:28:39.0000] <annevk>
qq[IrcCity]: irrespective of that, the Encoding standard applies to all MIME types

[03:28:51.0000] <qq[IrcCity]>
it’s a stage after decoding, not before.

[03:29:07.0000] <annevk>
qq[IrcCity]: actually, part of the HTML parser handles decoding

[03:29:14.0000] <qq[IrcCity]>
HTML decoding rules apply only to HTML.

[03:30:01.0000] <qq[IrcCity]>
and HTML5 make a special provision abour “irrelevent” confidence.

[03:30:19.0000] <qq[IrcCity]>
when browser operates in its internal text encoding.

[03:31:00.0000] <annevk>
I see, well, have a nice day

[03:47:43.0000] <qq[IrcCity]>
annevk, I think W3C people missed your out-of-context “Authors must use the utf-8” thing in CR-encoding-20140916, and possibly will be amazed with such your “novel” ideas as applying BOM sniffing to all media types including binaries ☺

[03:47:55.0000] <qq[IrcCity]>
may I quote this chat in mailing lists?

[04:32:26.0000] <qq[IrcCity]>
given the channel has logs publicly readable at krijnhoetmer.nl, I’ll proceed to quote the conversation without explicit permission.

[04:36:28.0000] <annevk>
Hah, you're in for a surprise ;-)

[04:37:06.0000] <annevk>
But yeah, feel free to quote. I tried to help you out, but it seems like you had some set of answers already

[04:44:02.0000] <qq[IrcCity]>
sure, I’m conservative.    my “set of answers” is based on original HTTP/1.1, not diluted by accommodation to idiocy.

[04:44:27.0000] <annevk>
qq[IrcCity]: please stay civil

[04:46:52.0000] <qq[IrcCity]>
naïve people here.    admins of httpd software were told for 17 years (since RFC 2068 till HTML5) they must specify Content-Type: text/whichever, charset=actual.   many of them ignored it.

[04:47:50.0000] <qq[IrcCity]>
now you make BOM sniffing mandatory and hope it would be universal solution ☺

[04:50:14.0000] <annevk>
sounds about right

[04:52:06.0000] <qq[IrcCity]>
and naïve Prof. Dürst who boasts he pioneered reliability of heuristic UTF-8 detection as early as in 1997, but seemingly unaware how modern broswers “detect” UTF-8 :D

[04:56:59.0000] <qq[IrcCity]>
I would look to see what Martin J. Dürst would do when, eventually, learned about the algorithm promulgated by Anne van Kesteren and company.   what would he say to Anne.

[04:57:30.0000] <annevk>
Pretty sure he knows about it

[04:58:55.0000] <qq[IrcCity]>
if the stream starts with «\357\273\277», then it’s damn UTF-8, no matter the fourth byte is \377 :D

[05:18:25.0000] <qq[IrcCity]>
one big problem: major browsers ceased to honour values in Content-Type, and not only for text/html.   and two narrower cases: 1. broken text/plain (already),

[05:18:28.0000] <qq[IrcCity]>
2. such novelties as “the Encoding standard applies to all MIME types” (yet to happen to application/* and so on).

[05:34:18.0000] <nox>
How is text/plain broken?

[05:36:07.0000] <qq[IrcCity]>
nox, did you see test cases at http://www.superstructure.info/browser/compromised/toxic-sniffing.html#better ?

[05:36:59.0000] <qq[IrcCity]>
one should enter \357\273\277 and so on manually, of course.

[05:39:41.0000] <nox>
I don't understand.

[05:39:47.0000] <nox>
What spec does that test follow?

[05:42:24.0000] <qq[IrcCity]>
nox, testing compliancy with RFC 2616 was initially in mind.   RFC 7231 is somewhat vague about Content-Type, but major browsers defy even its relaxed provisions.

[05:42:55.0000] <nox>
Where is the accommodation to idiocy?

[05:44:20.0000] <qq[IrcCity]>
nox: overriding explicitly serviced «charset=» with own guesses.   BTW, what is no-sniff-flag?

[05:48:14.0000] <qq[IrcCity]>
in other words, Google Chrome tells its user that one lamer qq[IrcCity] mistook «charset=» and it (Google) knows better what was intended meaning.

[05:49:04.0000] <qq[IrcCity]>
even when the text its claim to be UTF-8 has \377 in the fourth octet.

[05:49:16.0000] <nox>
What is that text?

[05:49:34.0000] <nox>
The page is lacking many information. What was the actual charset you intended to transmit?

[05:51:37.0000] <qq[IrcCity]>
nox, there is a simpler test case at http://course.irccity.ru/ya-yu-9-amp.txt but about toxic UTF-16.   two minutes, about to made the same for UTF-8.

[05:53:07.0000] <nox>
qq[IrcCity]: And why would \377 as the fourth octet change things btw?

[05:53:50.0000] <qq[IrcCity]>
from the point of view of RFC 2616, it’s at all irrelevant.

[05:54:15.0000] <qq[IrcCity]>
but it can show madness of BOM sniffing better.

[05:55:51.0000] <nox>
I see.

[05:56:07.0000] <nox>
Interestingly, forcing charset to Windows-1251 on that last link doesn't change anything in Safari.

[05:57:11.0000] <qq[IrcCity]>
http://course.irccity.ru/p-guillemet-yi-ya.txt shows toxic UTF-8.

[05:57:26.0000] <nox>
qq[IrcCity]: Then again, the question is whether your examples are the majority, or whether actually honouring 'charset' breaks more things.

[05:58:22.0000] <qq[IrcCity]>
examples are not about majority.  they are about predictability.

[05:59:11.0000] <nox>
The rules you call bugs are predictable.

[06:01:08.0000] <qq[IrcCity]>
they are predictable only since some guys found certain WhatWG and developers agreed to follow recommendations.   they aren’t predictable in the old world where protocols did matter.

[06:02:12.0000] <nox>
You do realise that the specs are how they are because actually the majority never cared about honouring 'charset', even in the old world?

[06:02:45.0000] <qq[IrcCity]>
nox, which majority?   Russian-speaking sites mostly cared.

[06:03:17.0000] <qq[IrcCity]>
and nobody can predict new things will WhatWG invent tomorrow: UTF-8 sniffing for octet-stream or whatever.

[06:03:19.0000] <nox>
Dürst in a mail linked on the page says "Yes, the iso-8859-1 'default' was invalidated because there were  millions and millions of documents for which it would have been wrong, especially in Eastern Europe and Asia."

[06:03:23.0000] <nox>
Are you talking about something else?

[06:03:54.0000] <qq[IrcCity]>
nox, about overriding explicitly serviced charset, again.

[06:04:08.0000] <qq[IrcCity]>
not old HTTP default.

[06:07:12.0000] <nox>
So I guess this actually broke a Russian-speaking site somewhere?

[06:07:22.0000] <qq[IrcCity]>
what??

[06:07:39.0000] <nox>
Not honouring Content-Type.

[06:08:55.0000] <qq[IrcCity]>
what do you speaking about?   90%+ pages contained charset= if not in Content-Type, then in HTML <meta> in the worst case.

[06:10:03.0000] <qq[IrcCity]>
if I am barred from saying п»їя in Windows-1251 (although all four characters pertain to the codepage), then the protocol is not honoured anymore.   not a problem with HTML that may not start…

[06:10:30.0000] <qq[IrcCity]>
… from arbitrary characters anyway, but a problem for text/plain.

[06:12:17.0000] <nox>
My question is, is that an actual bug that actually breaks stuff, or is that just a theoretical problem that doesn't break anything in practice?

[06:12:39.0000] <nox>
You are not barred from saying such a thing in a text/plain document, you are barred from beginning a document with such a thing.

[06:12:43.0000] <nox>
No?

[06:14:55.0000] <nox>
Did you look at RFC5987 btw?

[06:18:26.0000] <nox>
Also, https://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-3.1.1.5

[06:19:08.0000] <qq[IrcCity]>
nox, how is RFC5987 relevant to the dispute?   it is related to our case (RFC 7231) like RFC 1522 (i18n of headers) is related to RFC 1521 (i18n of bodies).

[06:20:24.0000] <nox>
qq[IrcCity]: Yeah disregard that one, lost myself in tabs.

[06:20:39.0000] <nox>
Meant to ask whether httpbis had some changes planned in that area, apparently no.

[06:21:45.0000] <qq[IrcCity]>
nox: so you agree that browsers defy HTTP semantics 3.1.1.5, aren’t you?

[06:22:15.0000] <nox>
I agree, but I'm not sure it's actually important.

[06:23:32.0000] <qq[IrcCity]>
I’m not aware anyone complained before me about that.

[06:24:20.0000] <qq[IrcCity]>
I made Codepage Explorer just for the case, to show an actual application that can be broken by unlucky combination of octets.

[06:25:33.0000] <nox>
It's a nice catch, but I'm afraid you'll just be told that it's not actually a problem in real world and thus nothing will be changed.

[06:27:50.0000] <qq[IrcCity]>
not a nice thing for me, since my trust in browsers ended abruptly.    this is not that Internet I was accustomed to.

[06:28:49.0000] <qq[IrcCity]>
nowadays browsers lie you twice more than despisable Windows lied users in 1990s.

[09:17:47.0000] <annevk>
Ugh

[09:18:22.0000] <annevk>
ECMAScript still requires that `var x = new ArrayBuffer(10); postMessage(x, "*", [x]); console.log(x.byteLength)` throws, but no implementation does that

[09:36:27.0000] <annevk>
Oh, actually, I'm mistaken

[10:33:45.0000] <Domenic>
Hmm I think it does

[10:34:21.0000] <Domenic>
Last I checked TC39 still wants to try that. And no implementers want to try that. So awesome.

[16:27:22.0000] <MikeSmith>
I don't understand how it's possible that I never knew about http://devdocs.io/ before now

[16:27:32.0000] <MikeSmith>
do other people here know about it already?

[16:28:37.0000] <MikeSmith>
it seems extremely well done, as far as putting some very good UI/UX around aggregated docs from a bunch of different sources (e.g., MDN, but a ton of other stuff as well)

[16:40:37.0000] <jgraham>
Oh, I had heard of that but now it has Rust docs

[16:40:56.0000] <jgraham>
Seems like it could be more convenient than trying to remember where it installs them and start a web server


2015-09-27
[17:26:42.0000] <MikeSmith>
jgraham: yeah I'm pretty impressed with it

[17:28:54.0000] <MikeSmith>
christ it works offline as well

[17:28:57.0000] <MikeSmith>
amazing

[17:38:53.0000] <MikeSmith>
http://devdocs.io/offline

[17:39:38.0000] <MikeSmith>
hmm, 「Fatal error: [Exception... "File error: Corrupted"  nsresult: "0x8052000b (NS_ERROR_FILE_CORRUPTED)"  location: "JS frame :: https://ton.twimg.com/tweetdeck-web/web/scripts/default.45f48adf49.js :: i.getPreviousStorage/t< :: line 16"  data: no]」

[17:39:49.0000] <MikeSmith>
in Nightly

[17:39:57.0000] <MikeSmith>
/me asks on #developers

[19:17:05.0000] <MikeSmith>
annevk: the UX around what I when I navigate to things like https://fetch.spec.whatwg.org/#cors-preflight-request is suboptimal

[19:19:11.0000] <MikeSmith>
annevk: in that, my browser scrolls "This is named a CORS-preflight request." to the top of the viewport, but the actual details that define what a CORS-preflight request is are above the sentence in document order, so I then need to know enough to know that I have to manually scroll up to get to them

[19:20:25.0000] <MikeSmith>
annevk: but I think a lot of normal users when they see "This is named a CORS-preflight request." are just going to say, What is? and be baffled and not necessarily get that they just need to scroll up a couple of lines

[19:24:54.0000] <MikeSmith>
annevk: btw there a handful of good fetch/SW/CORS questions at SO that are unanswered

[19:25:08.0000] <MikeSmith>
e.g., http://stackoverflow.com/questions/32795725/will-service-worker-query-cache-algorithm-allow-expression-matching-url-paths

[19:25:42.0000] <MikeSmith>
http://stackoverflow.com/questions/tagged/fetch-api?sort=unanswered

[19:26:14.0000] <MikeSmith>
http://stackoverflow.com/questions/tagged/service-worker?sort=unanswered

[19:26:39.0000] <MikeSmith>
http://stackoverflow.com/questions/tagged/cors?sort=unanswered

[19:28:10.0000] <MikeSmith>
including odd stuff like http://stackoverflow.com/questions/32669605/what-is-domexception-entry-already-exists that I guess is maybe just a blink bug that somebody working on the SW implementation needs to troubleshoot

[22:10:40.0000] <MikeSmith>
annevk: since the Fetch spec no longer even defines the term "author request header" (former "custom request header"), I think it's become a lot harder for webdevs to know which headers will trigger a CORS preflight request and which won't

[23:22:40.0000] <Domenic>
heycam|away or anyone: are dictionary constructors actually used anywhere? /cc Sebmaster

[01:34:36.0000] <MikeSmith>
annevk: should the Fetch spec mention Last-Event-ID?

[07:41:56.0000] <gsnedders>
SimonSapin: I'm not sure I'd call it a "reference" impl. Maybe an experimental implementation, used for prototyping?

[07:43:31.0000] <gsnedders>
SimonSapin: I know Hixie had his own impl, I think prior to html5lib, in Sawzall?

[07:44:20.0000] <gsnedders>
SimonSapin: I think once html5lib came into being Hixie stopped touching his impl much, but you'd have to ask him.

[07:44:29.0000] <gsnedders>
SimonSapin: maybe a year or two later

[07:45:05.0000] <gsnedders>
SimonSapin: but yeah, by ~2008 html5lib was the main implementation used for trying out stuff, till the parser landed in Gecko

[08:05:17.0000] <Ms2ger>
TIL about Sawzall

[09:19:44.0000] <Domenic>
Starting to get serious about upstreaming jsdom tests into web-platform-tests. First step: https://github.com/tmpvar/jsdom/pull/1246 (main portions: https://github.com/tmpvar/jsdom/pull/1246/files#diff-3b2955787a83cfa5960bcd95edb33a9cL5 ported to https://github.com/tmpvar/jsdom/pull/1246/files#diff-a379fbce7fde48a69f04f6e31112f800R1)

[10:11:58.0000] <annevk>
MikeSmith: not sure how to answer most of those

[10:12:22.0000] <annevk>
MikeSmith: I thought the specification was fairly clear now when a preflight is triggered

[10:13:15.0000] <annevk>
MikeSmith: Last-Event-ID doesn't trigger it because the API that uses it doesn't set the https://fetch.spec.whatwg.org/#unsafe-request-flag

[10:13:35.0000] <annevk>
MikeSmith: https://fetch.spec.whatwg.org/#unsafe-request-flag is a bit of a cop-out, in my opinion, but seems to be the way the world works

[10:20:21.0000] <qq[IrcCity]>
to which mail list should I go to discuss encoding.spec.whatwg.org?

[10:24:21.0000] <annevk>
qq[IrcCity]: if you want to email you can use whatwg⊙wo

[10:24:29.0000] <annevk>
qq[IrcCity]: filing an issue on GitHub is preferred, however

[10:30:16.0000] <qq[IrcCity]>
annevk: is there a web for filing issues?

[10:30:24.0000] <qq[IrcCity]>
a web form

[10:30:34.0000] <annevk>
qq[IrcCity]: GitHub has forms, yes

[10:31:10.0000] <annevk>
qq[IrcCity]: the standard has links

[10:31:25.0000] <qq[IrcCity]>
yes, just following them.

[11:08:44.0000] <MikeSmith>
annevk: I think https://fetch.spec.whatwg.org/#unsafe-request-flag is fine as far as mqking things clear for UA implementors. But think for webdevs a problem is that they don't know at what point particular headers that get set by the UA are added, or just in general don't understand that headers which get set by the UA are not relevantーbecause the spec no longer states that explicitly (no longer speak

[11:08:50.0000] <MikeSmith>
s of "author request headers" or "custom request headers")

[11:09:31.0000] <MikeSmith>
annevk: please see my answer at http://stackoverflow.com/questions/32795489/http-headers-which-cause-preflight-clarification/32806651#32806651 and let me know if I got anything wrong there

[11:10:11.0000] <MikeSmith>
but if that's right, maybe I can take a shot at writing up something similar as a non-normative note for the spec

[11:13:30.0000] <MikeSmith>
Domenic: big +1 to the test-upstreaming effort

[11:13:52.0000] <MikeSmith>
https://github.com/tmpvar/jsdom/pull/1246#issuecomment-143578179 from Joris-van-der-Wel is good feedback

[11:14:51.0000] <MikeSmith>
frewsxcv: see https://github.com/tmpvar/jsdom/pull/1246#issuecomment-143578179

[11:16:04.0000] <MikeSmith>
maybe we need to consider dropping some of those testsーespecially any for which the implementor feedback is that the test was "almost useless for me when I was implementing"

[11:16:55.0000] <MikeSmith>
also maybe we need to think about how to provide a better way for implementors to give feedback about tests as they are implementing

[11:17:55.0000] <MikeSmith>
as it stands now, in the case where an implementor ends up ignoring a test because it's irrelevant, that's valuable info that we're just losing

[11:20:10.0000] <MikeSmith>
「Are such tests just a relic of the past, or is this really part of "the" style」indeed

[11:24:35.0000] <MikeSmith>
some parts of the test suite are a real mixed bag of tests that Ms2ger and jgraham and reviewers and other implementors know to be good tests (that were either written by implementors or by the core reviewers), but then also with tests that we know to be cruft but that got grandfathered in or accepted just because they're not outright wrong or whatever

[11:26:33.0000] <MikeSmith>
the only other good way for somebody to be able to tell at this point is for them to also have some knowledge about which test submittors are relevant and which sort of aren't, and then to look at the provenance of any questionable test and set who submitted it

[11:30:01.0000] <MikeSmith>
in the end though I think implementors, from just looking at test, can tell whether the test was written by an implementor or somebody who understands how to test implementations, vs being written by somebody who wrote a certain test case for the sake of having a certain test case

[11:30:35.0000] <MikeSmith>
jgraham: see https://github.com/tmpvar/jsdom/pull/1246#issuecomment-143578179

[11:33:30.0000] <MikeSmith>
qq[IrcCity]: I hope you are being considerate of other people's time on this text/plain sniffing thing. The answers annevk gave you here yesterday or so were basically the same answers I have you days earlier elsewhere, and are going to be the same answers you get from others you ask

[11:35:06.0000] <MikeSmith>
qq[IrcCity]: and being uncivil and dismissive and using words like "idiots" repeatedly isn't going to motivate people to want to pay much attention

[11:39:41.0000] <qq[IrcCity]>
MikeSmith: I am right, whereas Anne is not.  due to this “Living Standard” compatibility with Internet media types (as used in MIME) is broken at least in two points.

[11:40:09.0000] <qq[IrcCity]>
first, the problem you already know.

[11:41:10.0000] <qq[IrcCity]>
second, “legacy encoder” proposed by annevk will produce incorrect results in case of ASCII and ISO 8859-1, due to conflation of these who with Windows-1252.

[11:41:24.0000] <qq[IrcCity]>
* of these two

[11:42:51.0000] <qq[IrcCity]>
this document is short of IETF quality I’m accustomed to.

[11:43:43.0000] <qq[IrcCity]>
because its main agenda is burning abything but UTF-8, not correctness.

[11:47:27.0000] <qq[IrcCity]>
and, as far as I understood, people like Julian Fischke are not willing to collaborate with WhatWG due to such attitude.

[11:48:04.0000] <Domenic>
MikeSmith: I took JoWie's comment more as "this didn't help guide me in the implementation," or maybe "enabling this test gave me no confidence that I'd done things right," instead of "this test does not provide good coverage." I think in general bad tests are going to happen but as long as they increase coverage even a little, it's a plus. Same with

[11:48:04.0000] <Domenic>
"duplicated" tests where you have two tests testing the same constraint in slightly different ways; you could go to a lot of effort to weed them out, but the added coverage is nice and the pain isn't much.

[11:48:36.0000] <Domenic>
MikeSmith: that said I do feel like WPT has a lot of generative tests that are too smart for their own good. E.g. my issue https://github.com/w3c/web-platform-tests/issues/2038

[11:51:48.0000] <Domenic>
qq[IrcCity]: what do you hope to gain by engaging in the WHATWG, with that attitude. What concrete goal do you have, besides being "right" (in your mind only).

[11:53:12.0000] <qq[IrcCity]>
Domenic: to stop and reverse dilution of HTTP/1.1 that started to corrupt browsers since about 2014.   not more, not less.

[11:53:26.0000] <Domenic>
qq[IrcCity]: so you want to change browsers?

[11:53:55.0000] <JoWie>
yes, i had a failure in that generative test and it was very hard to figure out what I had implemented wrong.  I eventually wrote more jsdom custom tests in order to track it down more easily

[11:54:16.0000] <JoWie>
it was indeed not about coverage

[11:54:51.0000] <JoWie>
this WPT felt more of a pass/fail check instead of a debugging aid

[11:55:33.0000] <JoWie>
and if i wanted to verify that the test actually tests what the spec specifies, it would take a lot of effort (there actually was a spec bug in this instance!)

[11:55:47.0000] <Domenic>
oh yeah i remember that...

[11:57:01.0000] <qq[IrcCity]>
Domenic: of course, I can invent patches for FOSS browsers and deploy them for the use of like-minded people (it’s the plan B).  but now I’m trying to persuade this community that extermination agenda is unwise.

[11:57:37.0000] <Domenic>
qq[IrcCity]: you have this backward. We specify what browsers do. Browsers do what is web compatible.

[11:57:45.0000] <Domenic>
qq[IrcCity]: you can't convince the spec editor to change this way.

[11:58:17.0000] <Domenic>
qq[IrcCity]: instead you need to find all the web pages that depend on the current behavior on the entire internet, fix them. Then, you can ask browsers to change to the behavior you prefer, since that change will no longer break the internet. THEN, you change the spec.

[11:58:40.0000] <JoWie>
unless you want another quirks mode

[12:00:17.0000] <qq[IrcCity]>
did anybody in WHATWG or Mozilla asked how many text/plain pages broke when annevk deployed his sniffer?

[12:00:26.0000] <Domenic>
qq[IrcCity]: annevk didn't deploy his sniffer O_O

[12:00:46.0000] <MikeSmith>
oh, I'd forgotten that JoWie is Joris-van-der-Wel. Hi JoWie

[12:00:49.0000] <Domenic>
qq[IrcCity]: browsers have had sniffers since 1995. The IETF specced a fantasy. annevk and the other editors of Encoding specced reality.

[12:00:52.0000] <qq[IrcCity]>
but somebody in Mozilla did it based on his insistence.

[12:00:58.0000] <JoWie>
haha hi

[12:01:01.0000] <Domenic>
qq[IrcCity]: no, again, you have it backward

[12:01:07.0000] <MikeSmith>
JoWie: :-)

[12:01:11.0000] <qq[IrcCity]>
Domenic, I tested my cases in Firefox 11.   all right!

[12:01:53.0000] <JoWie>
if you shuffle & discard random letters in my name you can end up with "JoWie" :P

[12:02:04.0000] <MikeSmith>
heh

[12:02:09.0000] <MikeSmith>
I like that algorithm

[12:02:27.0000] <JoWie>
that is why the W is capitalized

[12:02:45.0000] <MikeSmith>
"Step 1: Shuffle and discard random letters."

[12:03:34.0000] <MikeSmith>
Domenic: roger all that (about JoWie comments and generative+duplicated tests)

[12:04:09.0000] <qq[IrcCity]>
Domenic: of course there were sniffers in 1995, in the age of HTTP/1.0.   so what?

[12:04:30.0000] <Domenic>
qq[IrcCity]: do you not understand what I mean when I say you have it backward?

[12:04:51.0000] <qq[IrcCity]>
no, I do not.

[12:05:22.0000] <Domenic>
qq[IrcCity]: we specced what browsers did; we did not spec things and then tell browsers to do them.

[12:05:48.0000] <qq[IrcCity]>
nobody before c. 2014 overrode Content-Type based on values of first three octets.

[12:05:52.0000] <MikeSmith>
JoWie: yeah the situation "if i wanted to verify that the test actually tests what the spec specifies, it would take a lot of effort" is something we should try harder to make the test suite avoid. At a minimum, the test suite should not cause implementors to waste time. It should rather *save* time for implementors.

[12:06:08.0000] <Domenic>
qq[IrcCity]: here is a 2005 document proving you wrong: https://developer.mozilla.org/en/docs/How_Mozilla_determines_MIME_Types

[12:06:19.0000] <qq[IrcCity]>
this was an (incorrect) generalization of HTML6 specs to all text/*.

[12:06:26.0000] <qq[IrcCity]>
developers made a mistake.

[12:06:32.0000] <qq[IrcCity]>
* HTML5

[12:06:55.0000] <qq[IrcCity]>
Domenic: when Firefox 11 was issued?

[12:07:01.0000] <Domenic>
qq[IrcCity]: 2012

[12:07:19.0000] <qq[IrcCity]>
again, I tested my cases.  at least one with toxic UTF-16LE.

[12:07:33.0000] <Domenic>
qq[IrcCity]: Firefox 11 was released about 2 months before the mimesniff spec existed

[12:08:03.0000] <Domenic>
qq[IrcCity]: and Firefox (and IE, per the document) have been sniffing text/plain since at least 2005.

[12:08:35.0000] <JoWie>
MikeSmith: yea that would be much better.

[12:08:40.0000] <qq[IrcCity]>
Domenic: they didn’t try to override Content-Type without a strong pretext.

[12:08:52.0000] <Domenic>
qq[IrcCity]: that is just false, according to the linked document

[12:09:10.0000] <MikeSmith>
qq[IrcCity]: when you make comments like "did anybody in WHATWG or Mozilla asked how many text/plain pages broke when annevk deployed his sniffer" you reveal some serious basic misunderstandings about cause-and-effect around browser implementations of this stuff. And then you don't listen when one of us takes time (as Domenic is doing now) to try to (re)explain some of what you're not understanding about

[12:09:16.0000] <MikeSmith>
 it.

[12:09:27.0000] <Domenic>
qq[IrcCity]: if you are not going to accept evidence of fact, and cling to this fantasy version of history where people actually implemented HTTP perfectly (nobody did), I guess I'm done here.

[12:10:10.0000] <Domenic>
Parting words: stop trying to do things backward. First, fix all the pages on the internet that depend on text/plain sniffing working. Then, convince browser vendors to change to the algorithm you prefer, instead of the algorithm they have been using since 2005 (or longer; that is just the document last revision date). Finally, ask to change the spec.

[12:10:18.0000] <JoWie>
MikeSmith: So far my/our procedure for testing is #1 Write tests with for the new feature (using a coverage tool). #2 Check if WPT agrees or goto #1

[12:10:34.0000] <JoWie>
so we have a lot of local test which should be WPT

[12:10:39.0000] <JoWie>
tests

[12:12:23.0000] <MikeSmith>
qq[IrcCity]: as annevk pointed out earlier you seem to want some answer that you're not hearing and you're not going to hear because it conflicts with reality. Nobody is claiming that the way things work for this now are the ideal; instead they're just the reality and we did not make that reality 2 years ago or whatever, and we are not in a position to change it. Nobody is in a position to change it, and

[12:12:29.0000] <MikeSmith>
 it's not likely to ever change (for reasons that multiple people have pointed out to you).

[12:12:40.0000] <MikeSmith>
JoWie: yeah

[12:12:53.0000] <MikeSmith>
JoWie: I think that is a common pattern for anybody implementing

[12:15:37.0000] <MikeSmith>
maybe Mozilla has a workflow around that iteration and upstreaming that could be repurposed by other implementors/projects

[12:16:44.0000] <MikeSmith>
I know jgraham has put a lot of work into helping create a workflow within Mozilla that feeds into wpt (and that feeds wpt into Mozilla CI)

[12:17:34.0000] <qq[IrcCity]>
Domenic: with browsers’ habits as of 2005, an end user had a possibility to override encoding that browser determined (via either HTTP/1.1 or sniffing).   now an end user can’t do anything in Mozilla, Google Chrome, MS IE, and (reportedly) Safari.

[12:18:03.0000] <qq[IrcCity]>
can’t do anything in the toxic BOM condition.

[12:18:49.0000] <qq[IrcCity]>
it’s even worse than simply breaking compaticility.

[12:21:20.0000] <JoWie>
it would be great if all the local tests of all the browsers would be in WPT, i can imagine it would help compatibility issues a lot

[12:21:55.0000] <qq[IrcCity]>
what is WPT?

[12:29:02.0000] <astearns>
qq[IrcCity]: https://github.com/w3c/web-platform-tests

[12:29:33.0000] <MikeSmith>
JoWie: yeah a goal would be to have browser projects change a bit such that the were developing tests in such a way that those compatibility issues were greatly reduced

[12:30:13.0000] <MikeSmith>
IE/Edge does not support document.execCommand('copy') yet, right?

[12:35:03.0000] <MikeSmith>
shit all of http://www.quirksmode.org/ is gone

[12:36:41.0000] <MikeSmith>
I guess ppk forgot to renew the domain registration or something

[12:37:01.0000] <MikeSmith>
seems to have disappeared within the last 3 weeks

[12:42:38.0000] <estellevw>
MikeSmith quirksmode is up for me.

[12:45:20.0000] <MikeSmith>
estellevw: does it show what it should show or does it show some domain-parking thing?

[12:46:18.0000] <estellevw>
i can get to this page http://www.quirksmode.org/compatibility.html from the home page

[12:46:24.0000] <estellevw>
looks totally normal

[12:46:30.0000] <MikeSmith>
weird

[12:47:11.0000] <MikeSmith>
estellevw: you sure you're not looking at cached copy?

[12:47:23.0000] <estellevw>
i never go to quirksmode

[12:47:33.0000] <estellevw>
so it’s not cached locally

[12:47:38.0000] <qq[IrcCity]>
MikeSmith: no problems with http://www.quirksmode.org/ as well.

[12:48:23.0000] <MikeSmith>
ok, very odd

[12:48:53.0000] <Sebmaster>
This.... Is interesting, I get a parking page too

[12:49:26.0000] <qq[IrcCity]>
different NSes?

[12:49:52.0000] <MikeSmith>
yeah whois says "Registrant Name:Pending Renewal or Deletion"

[12:50:09.0000] <MikeSmith>
so maybe DNS hasn't propogated fully or something

[12:50:34.0000] <qq[IrcCity]>
it’s plausible.

[12:51:01.0000] <qq[IrcCity]>
is the person in charge alerted?

[12:51:30.0000] <estellevw>
their whois reads Tech Name:Pending Renewal or Deletion

[12:52:08.0000] <estellevw>
but their expiry date is 2016-05-22

[12:52:12.0000] <estellevw>
so something weird is up

[12:54:37.0000] <estellevw>
i tweeted at him. Not sure if that’s the best way to go

[12:56:43.0000] <MikeSmith>
ah I just pinged ppk as well https://twitter.com/sideshowbarker/status/648224531610402816

[12:57:21.0000] <qq[IrcCity]>
MikeSmith:  www.quirksmode.org has address 194.109.6.98, so you may override your DNS “doing the best thing for end users”™

[12:57:41.0000] <MikeSmith>
heh

[12:57:44.0000] <MikeSmith>
thanks yeah

[12:58:28.0000] <MikeSmith>
estellevw: btw did you tweet recently about being on the job market (so I can retweet)

[12:59:08.0000] <estellevw>
i didn’t tweet it since my boss follows me, but you can tweet it ;)

[13:00:25.0000] <MikeSmith>
k

[13:32:12.0000] <jgraham>
MikeSmith, Domenic: I think some of the generative tests have given us incredible bang-for-buck. For example hand-writing all the idlharness.js tests would be tedious makework that people would likely do in a much more halfassed way than the current implementation (even allowing that the implementation could use updating for missing features in WebIDL). So I reject the idea that those kinds of tests are a bad idea (and, with my "implementor" hat on,

[13:32:18.0000] <jgraham>
... them as "mostly useless")

[13:33:03.0000] <jgraham>
I agree that there are tradeoffs, and I certainly see the appeal of very simple tests too.

[13:33:37.0000] <jgraham>
As or upstreaming tests, the workflow is all open-source of course.

[13:34:14.0000] <jgraham>
It's part of wptrunner.

[13:54:59.0000] <JoWie>
they were just "mostly useless" for my specific issue

[13:55:07.0000] <JoWie>
not in general

[13:56:10.0000] <JoWie>
i am not against generative tests in itself. just that some of them give very little issue when things fail

[13:56:19.0000] <JoWie>
and it takes a lot of effort to recreate the state they are testing

[13:56:55.0000] <JoWie>
writing them in a different way would go a long way into solving that

[14:15:30.0000] <jgraham>
JoWie: Yes, I entirely agree that's one of the tradeoffs. Certainly the same coverage with simpler-to-debug tests would be good.

[14:39:34.0000] <qq[IrcCity]>
for several days I blamed WHATWG for adding subtle bugs to browsers.   but when examined (in mind) my own code of CGI application that converts C string escape codes to octets about to show in a codepage, found a subtle bug in processing 1- and 2-digits octals.  It’s ironical.

[15:39:25.0000] <terinjokes>
hrm, wondering if anyone knows why SRI only applies for <link> and <script> and not other subresources

[15:53:28.0000] <terinjokes>
such as <embed> and <object>

[16:16:56.0000] <MikeSmith>
terinjokes: I only vaguely remember knowing why at one time but I don't recall now

[16:30:53.0000] <terinjokes>
MikeSmith: interesting


2015-09-28
[17:53:38.0000] <__n0a>
hi, Id like to know why https://developer.mozilla.org/en-US/docs/Web/API/Body#Methods doesn't have a document method

[17:54:16.0000] <__n0a>
is there a reson to not match https://xhr.spec.whatwg.org/#xmlhttprequestresponsetype ?

[17:54:21.0000] <__n0a>
reason*

[17:54:53.0000] <__n0a>
(fetch API)

[17:57:25.0000] <__n0a>
annevk: any idea?

[17:59:56.0000] <__n0a>
shouldn't https://github.com/slightlyoff/ServiceWorker/issues/462 be on the fetch repo?

[18:03:36.0000] <__n0a>
jgraham: ?

[23:51:16.0000] <annevk>
MikeSmith: I would be happy accepting a clarification to the text that explains CORS preflights

[23:52:05.0000] <annevk>
MikeSmith: I'd imagine it would say something about only headers set directly through XMLHttpRequest and fetch() being qualified for being checked against the whitelist due to the unsafe-request flag which is only set for those APIs

[23:52:27.0000] <annevk>
MikeSmith: and I guess you could point out that therefore EventSource's Last-Event-ID does not cause a preflight

[00:05:00.0000] <MikeSmith>
annevk: OK, I'll make some time to write up a PR

[00:05:37.0000] <annevk>
MikeSmith: in general pretty happy accepting CORS clarifications

[00:05:52.0000] <annevk>
MikeSmith: it's pretty hard it turns out

[00:06:16.0000] <MikeSmith>
I think webdevs have a hard time with some of it, yeah

[00:06:51.0000] <MikeSmith>
part of it is that the server-side systems they use don't make it all as easy as they could

[00:07:18.0000] <MikeSmith>
and part of it is that the docs at MDN and elsewhere could be made more clear as well

[00:08:07.0000] <MikeSmith>
I personally don't think the spec itself is the best place to pile in a lot of informative details just for webdevs

[00:08:34.0000] <MikeSmith>
though that said I think it should have just a few more

[00:17:32.0000] <annevk>
MikeSmith: well, someone has to read all the information in the spec to create all those other materials

[00:19:54.0000] <MikeSmith>
sure, so it needs to be clear enough for those people and/or they can ask in places like this for clarification

[00:20:55.0000] <MikeSmith>
but anyway that's a small(er) set of people (the people who contribute MDN and what not) and not just average webdevs

[00:21:29.0000] <annevk>
The worst is of course if they end doing up what we had to do in '04, reverse engineer browsers

[00:21:54.0000] <annevk>
Although that might get us a few more editors :-P

[00:45:19.0000] <MikeSmith>
hah

[00:45:30.0000] <MikeSmith>
secret strategy for creating more editors

[01:44:17.0000] <mkwst>
terinjokes: SRI only applies to those elements because the current spec is basically a test to check that we can actually verify integrity on the wild and crazy internet.

[01:44:42.0000] <mkwst>
terinjokes: Basically, they decided to do the simplest thing possible, make sure it works, and then expand it based on that experience.

[01:45:04.0000] <mkwst>
terinjokes: Tacking `integrity` attributes onto other elements as necessary is an obvious next step.

[01:45:35.0000] <annevk>
Well, it also applies to fetch()

[01:46:35.0000] <mkwst>
annevk: Right. I'm surprised they went for that, given the justification for stripping everything else out. *shrug*

[01:47:22.0000] <annevk>
mkwst: I think the main problem with the prior version was browsing contexts, everything else was probably fine

[01:47:36.0000] <mkwst>
?

[01:52:41.0000] <annevk>
mkwst: I might misremember

[01:53:26.0000] <mkwst>
I kinda stopped following the details. I figure the four folks editing the doc have things in hand.

[02:05:51.0000] <mkwst>
https://twitter.com/ryosukeniwa/status/648201610800185344 is a bit frustrating.

[02:06:52.0000] <annevk>
Well, to be fair to Apple, the way SW was developed wasn't exactly business as usual

[02:07:04.0000] <mkwst>
The conversation around it is a bit flamey, but if WebKit folks really see CR as the point to _start_ reviewing, then they're pretty substantially out of step with the way Chrome folks see CR (which boils down to "We're done here, time to move on.").

[02:07:36.0000] <annevk>
Both seem wrong :-)

[02:07:41.0000] <mkwst>
Not trying to defend SW specifically, but I would agree with Alex's suggestion that it's been "ready for review" for more than a few days.

[02:08:06.0000] <MikeSmith>
rniwa is not at his best on twitter

[02:08:11.0000] <MikeSmith>
it's not his medium

[02:08:18.0000] <mkwst>
MikeSmith: But really, who is?

[02:08:25.0000] <MikeSmith>
true that

[02:08:29.0000] <annevk>
mkwst: they've given feedback before, fwiw

[02:08:30.0000] <jgraham>
I think it's fair to say that humanity is not at their best on twitter

[02:08:49.0000] <annevk>
mkwst: I remember that being mostly dismissed at the time

[02:08:57.0000] <mkwst>
annevk: Hope so! All I know is what I see on Twitter, so, yeah. I assume more is going on. :)

[02:09:30.0000] <annevk>
mkwst: but SW isn't really ready for CR

[02:09:44.0000] <jgraham>
Well don't tell Apple! ;)

[02:09:59.0000] <mkwst>
annevk: I assume you've told the Chrome folks that?

[02:10:03.0000] <annevk>
mkwst: and I can see why you might want to wait until CR or some such if you're overcommitted, at least at that point you know it's at least somewhat reviewed

[02:10:07.0000] <annevk>
mkwst: sure did

[02:10:14.0000] <mkwst>
annevk: good.

[02:10:18.0000] <Domenic>
later in the thread it's admitted that that's just an excuse for resource constraints/prioritization

[02:10:29.0000] <Domenic>
there are definitely specs where apple participates before CR

[02:10:34.0000] <MikeSmith>
with ryosuke in particular I think it's a mistake to give him too much of a hard time for stuff he (mis)states on twitter

[02:10:54.0000] <annevk>
mkwst: so much specifications get pushed through rather fast without anyone paying much attention

[02:11:08.0000] <Domenic>
e.g. all web components

[02:11:27.0000] <mkwst>
annevk: There's a tough balance between getting everyone on board, and ever shipping anything.

[02:11:43.0000] <mkwst>
annevk: and, of course, distinct priorities that drive decisions.

[02:12:15.0000] <mkwst>
annevk: I think it's safe to say that Apple and Google have different things they/we want to build. And that causes some tensions.

[02:12:25.0000] <mkwst>
Firefox too, to be fair.

[02:12:43.0000] <mkwst>
Also Opera. And Microsoft. And every web developer. :)

[02:13:37.0000] <howdoi>
How does one get the arguments of a proxy method call?

[02:13:44.0000] <mkwst>
jgraham: Would you mind commenting on https://github.com/w3c/web-platform-tests/pull/2205? It's not clear to me how best to deal with prefixed junk in WPT.

[02:13:46.0000] <howdoi>
as in if p is my proxy, on p.meow(1,2,3) in the handler (target, name) => (p,meow); but I am interested in (1,2,3) the arguments.

[02:14:18.0000] <howdoi>
/me sorry if ^ caused some noise in a serious discussion

[02:14:48.0000] <Ms2ger>
Solution: get rid of CRs

[02:15:28.0000] <howdoi>
Got it!

[02:15:35.0000] <howdoi>
apply, hmm thanks.

[02:16:46.0000] <mkwst>
Ms2ger: Nope. CR => PR => REC => patent protection.

[02:17:24.0000] <Ms2ger>
Lol

[02:18:06.0000] <Domenic>
lol indeed.

[02:18:46.0000] <mkwst>
*shrug* That's the value. I know you disagree with it, but that doesn't mean it's at all worthless. :)

[02:19:21.0000] <annevk>
Not sure that's really been established

[02:20:03.0000] <Ms2ger>
I don't disagree that patent protection is theoretically useful

[02:20:07.0000] <Domenic>
Just make sure nobody implements until it's in REC, since otherwise people might try to assert patents...

[02:20:38.0000] <mkwst>
Domenic: You know that's a strawman, right?

[02:21:27.0000] <Domenic>
mkwst: yes, thus "PSA: Web Components vs Extract Widget patent"

[02:22:17.0000] <howdoi>
Duh! that doesn't help

[02:22:20.0000] <Domenic>
If only we'd held off implementing web components until they were a REC!

[02:23:11.0000] <mkwst>
Domenic: I didn't say a path to REC prevented patent claims. I said it provided protection. Laywers like having clear processes that provide a framework for constructing a defense.

[02:24:21.0000] <Domenic>
mkwst: and my point is it's not actually helpful in practice---we have no evidence of it being so proven, and in fact evidence of the opposite, where because people implement pre-REC, patent claims happened and there was no protection present.

[02:25:54.0000] <mkwst>
Domenic: I disagree that this is evidence of the opposite. That is, of course trolls gonna troll. If idiotic claims go to court, the equally idiotic W3C process provides a clear defense.

[02:26:07.0000] <mkwst>
Domenic: In a perfect world, we wouldn't need it. The world, however, is idiotic. :)

[02:26:46.0000] <Domenic>
mkwst: the process provides a clear defense in the hypothetical world where implementations happen after REC.

[02:28:15.0000] <mkwst>
Domenic: I think you're taking too narrow a view of things, but I'm not a lawyer. *shrug*

[02:31:16.0000] <jgraham>
I thought that people believed that if someone who was actually covered by the patent policy tried to sue at some point before Rec. judges would take a very dim view of their behaviour

[02:34:14.0000] <Domenic>
Maybe there is an unclear defense yeah

[02:37:50.0000] <howdoi>
what's the status of streams.spec?

[02:38:21.0000] <Domenic>
howdoi: Living Standard ;)

[02:38:32.0000] <Domenic>
What do you mean more precisely

[02:38:41.0000] <mkwst>
jgraham: I'd like to write some tests that verify behavior on `http://localhost` and `http://127.0.0.1`. Is that something that should land in WPT? If so, how? :)

[02:38:48.0000] <howdoi>
which browser will implement it first ;) ?

[02:39:03.0000] <howdoi>
Edge! ?

[02:39:38.0000] <Domenic>
howdoi: much is implemented in Chrome since 43. Firefox has intent to implement. WebKit nighties have it but not Safari yet.

[02:40:37.0000] <jgraham>
mkwst: Well, that could be a problem I think

[02:40:52.0000] <howdoi>
Domenic: any flags must be enabled to use it? I am on Version 45.0.2454.99 not seeing it :(

[02:41:28.0000] <mkwst>
jgraham: https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy special-cases those kinds of origins for local development. I can test them in Blink's test runner, but I'd love to have generic tests if possible.

[02:41:30.0000] <jgraham>
mkwst: wpt only guarantees that web-platform.test and various subdomains exist, and doesn't make any specific assurances about ports

[02:41:46.0000] <Domenic>
howdoi: nope, enabled by default. No constructors yet though, and only readable streams.

[02:42:31.0000] <Domenic>
I wish there were a way to use the python runner without editing my hosts file :(

[02:42:36.0000] <howdoi>
Domenic: nice! any quick examples to try? typeof ReadableStream === 'function'; true! nice

[02:43:06.0000] <jgraham>
Domenic: wptrunner? You could use Firefox. Or Servo :)

[02:43:07.0000] <Domenic>
howdoi: there is a Chrome samples of fetch response body, do a quick search

[02:43:33.0000] <howdoi>
https://googlechrome.github.io/samples/fetch-api/fetch-response-stream.html this?

[02:43:49.0000] <jgraham>
mkwst: I think it would happen to work the way that Mozilla run the tests, I don't think it would work running from w3c-test.org

[02:43:55.0000] <Domenic>
Apparently on Unix you can use HOSTALIASES but that doesn't work on Windows even in Git bash...

[02:44:05.0000] <Domenic>
howdoi: yes

[02:44:13.0000] <mkwst>
jgraham: no, it couldn't work when running from the web.

[02:44:13.0000] <howdoi>
Killer, thanks!

[02:44:49.0000] <mkwst>
jgraham: I'll write some tests for Blink, and then point you to them to chat about how to get them into Firefox at least.

[02:45:53.0000] <jgraham>
mkwst: Yeah, at the very least if you write them in testharness.js format we have a way of running tests that can't be upstreamed for whatever reason

[02:45:58.0000] <howdoi>
mit stuff, heh heh cool

[02:47:06.0000] <jgraham>
Domenic: (if Chrome has a way of setting hosts using a pref or similar then we could use that in wptrunner)

[02:47:55.0000] <howdoi>
Domenic: the search can get better there, it's like O(n^2) now, right?

[02:49:05.0000] <howdoi>
So, res.body.getReader() gives use a reader

[02:50:51.0000] <howdoi>
reader.cancel() will result in reader.done hmm

[02:50:57.0000] <Domenic>
jgraham: this is for jsdom, so might be a tougher sell... I tried using the don't validate hosts thing but it still hung somewhere in the Python. I should try again maybe and debug harder.

[02:52:05.0000] <Domenic>
I should probably just fall back to the hosted tests though for contributors who don't want to muck with all the prereqs.

[02:53:20.0000] <mosulica>
Hi everyone, please follow us on twitter , https://twitter.com/nubomedia - PaaS for WebRTC - European FP7 project

[03:16:18.0000] <espadrine>
that sounded spammy

[03:43:59.0000] <annevk>
mkwst: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24091

[03:50:55.0000] <mkwst>
annevk: Without thinking about it too hard, locking it down to navigation (which would include iframes) seems like the right way to go.

[05:38:50.0000] <JonathanNeal>
TIL Chrome doesn’t respect changes to the rem size.

[05:45:01.0000] <JonathanNeal>
^ http://codepen.io/jonneal/pen/ZbBjPY

[06:08:48.0000] <zcorpan>
JonathanNeal: maybe you're hitting a minimum font-size issue?

[06:10:00.0000] <JonathanNeal>
zcorpan: yeah, although you can change the font-size to 0 or 1px and it honors that.

[06:10:43.0000] <JonathanNeal>
But I do wonder if Chrome / Safari has a minimum rem size.

[06:10:49.0000] <zcorpan>
hmm yeah it works fine for font-size

[06:11:00.0000] <JonathanNeal>
Like a holdover from the old says when you couldn’t define a font-size smaller than 9px.

[06:11:43.0000] <JonathanNeal>
Because the 30rem padding becomes 270px, and 270/30 is 9.

[06:12:05.0000] <JonathanNeal>
s/old says/old days

[06:13:29.0000] <zcorpan>
you still can't, except for 0

[06:13:46.0000] <zcorpan>
at least for me

[06:15:06.0000] <JonathanNeal>
zcorpan: did you try 1px?

[06:15:22.0000] <zcorpan>
yes. renders the same as 9px (on mac)

[06:15:39.0000] <JonathanNeal>
1rem rendered the same as 9px for me, but 1px rendered as 1px for me.

[06:17:06.0000] <mkwst>
JonathanNeal: https://crbug.com/new :)

[06:17:14.0000] <mkwst>
give me a bug ID, I can route it to the right folks.

[06:17:16.0000] <zcorpan>
ah yes, i see that in chrome canary also. opera beta 32 renders 1px as 9px though

[06:17:41.0000] <JonathanNeal>
Yay, everyone does it slightly different. That’s the way we like it.

[06:29:59.0000] <JonathanNeal>
mkwst: thanks https://code.google.com/p/chromium/issues/detail?id=536784&thanks=536784&ts=1443446992

[06:31:10.0000] <mkwst>
JonathanNeal: Thanks!

[06:47:44.0000] <wanderview>
mkwst: annevk: regarding that twitter thread about SW CR and apple review... I'd say its a better time to jump in due to the html spec integration more than anything... they can get a full picture now

[07:57:52.0000] <JoWie>
someone mentioned quirksmode.org being down with a registrar error

[07:58:03.0000] <JoWie>
this might be because xs4all is having issues since yesterday

[08:03:47.0000] <JoWie>
ah it was mikesmith that mentioned that

[08:04:24.0000] <JoWie>
http://tweakers.net/nieuws/105492/veel-xs4all-sites-zijn-onbereikbaar-door-probleem-domeinnaamregistratie.html (dutch)

[08:07:00.0000] <qq[IrcCity]>
JoWie: was it a transient registrar problem, in short?

[08:09:31.0000] <annevk>
wanderview: https://twitter.com/cconcolato/status/648512201452584960?

[08:10:45.0000] <wanderview>
thanks

[08:17:19.0000] <terinjokes>
MikeSmith: ah, sounds good

[08:30:40.0000] <JoWie>
xs4all messed up in their book keeping or something

[08:30:48.0000] <JoWie>
and networksolutions killed all their domains

[08:31:06.0000] <JoWie>
but there is a 15 day grace period that xs4all has to resolve the issue

[08:51:29.0000] <igrigorik>
annevk: https://fetch.spec.whatwg.org/#concept-bodyinit-extract .. any reason why we don't have a clause for object -> JSON in that switch?

[09:20:02.0000] <Ms2ger>
TabAtkins, r? https://github.com/w3c/csswg-test/pull/891

[10:01:30.0000] <annevk>
igrigorik: how would that work?

[10:03:09.0000] <annevk>
igrigorik: see also https://github.com/whatwg/fetch/issues/47

[11:23:00.0000] <MikeSmith>
terinjokes: ? > MikeSmith: ah, sounds good

[11:23:23.0000] <MikeSmith>
terinjokes: maybe you were responding to what mkwst wrote earlier about the integrity attribute?

[11:23:27.0000] <terinjokes>
MikeSmith: why SRI only applies to two things

[11:23:30.0000] <MikeSmith>
annevk: http://stackoverflow.com/questions/32581503/microsoft-edge-blocked-cross-domain-requests-sent-to-ips-in-same-private-network

[11:23:46.0000] <terinjokes>
MikeSmith: probs, i was still half asleep when i replied

[11:24:11.0000] <MikeSmith>
annevk: "Internet pages are not able to frame Intranet pages, load images or resources from them, *send them CORS XHR requests*, etc."

[11:24:27.0000] <MikeSmith>
sorta seems to defeat the purpose of CORS

[11:25:43.0000] <MikeSmith>
「A public space address (internet) page was attempting to load a page with a private space address (intranet) in an iframe and Edge would refuse to load the intranet page with the same "Hmm, we can't reach this page" message, and with "SEC7117 Error" in the debug console. Turns out Edge doesn't like mixing internet/intranet zones (see this blog post for reasons why). Edge runs tabs in separate AppConta

[11:25:49.0000] <MikeSmith>
iners, and AppContainer network restrictions are sensitive to your network configuration."

[11:26:04.0000] <MikeSmith>
http://stackoverflow.com/a/32828629/441757

[11:34:27.0000] <annevk>
MikeSmith: it doesn't much

[11:34:41.0000] <annevk>
MikeSmith: you can't reliably tell what is intranet and what is not

[11:38:06.0000] <MikeSmith>
annevk: it seems like IE/Edge at least are attempting to do just that

[11:38:37.0000] <MikeSmith>
and when this fails in IE/Edge, it's not obvious to webdevs why it's failing

[11:38:40.0000] <annevk>
MikeSmith: they have some limits that other browsers should copy, but it's not robust

[11:38:45.0000] <MikeSmith>
OK

[11:41:25.0000] <annevk>
MikeSmith: e.g., IP-based authentication is not covered

[11:41:40.0000] <annevk>
MikeSmith: or intranets that use "public" IP addresses

[11:42:16.0000] <annevk>
MikeSmith: also I believe you cannot really them apart anymore with IPv6, but I don't know enough about that to be sure

[11:44:33.0000] <MikeSmith>
ah yeah

[12:48:47.0000] <gsnedders>
annevk: reminds me of Presto blocking stuff from public IPs to private-use IPs (and from private-use to localhost)

[12:49:49.0000] <gsnedders>
I mean such things do block a lot of attacks on intranets, even though they aren't perfect.


2015-09-29
[22:31:17.0000] <igrigorik>
annevk: thanks for the reference, followed up on the thread: https://github.com/whatwg/fetch/issues/47#issuecomment-143948846

[23:13:04.0000] <annevk>
gsnedders: yeah, mkwst is investigating writing a standard for it

[23:13:46.0000] <annevk>
igrigorik: you haven't really addressed the issue

[23:52:29.0000] <mkwst>
gsnedders, annevk: Yeah. I had a spec for this, and the group got cold feet after some challenges popped up. I'd like to bring it back up, but I'm loath to do so until I know how to do the blocking in Chromium so that it's not just an empty document.

[23:53:05.0000] <annevk>
mkwst: why does it have to be an empty document?

[23:53:24.0000] <annevk>
mkwst: is this related to Chromium making error pages same-origin?

[23:53:47.0000] <mkwst>
annevk: Hrm? No, sorry. Maybe I didn't understand the discussion.

[23:54:22.0000] <mkwst>
annevk: I mean that it's tough for our network stack to distinguish a priori an intranet address from an internet address before connection time.

[23:54:44.0000] <mkwst>
annevk: And we don't have enough context at the time that we're making a connection to determine whether we should block the former or not.

[23:54:44.0000] <annevk>
mkwst: oh

[23:54:58.0000] <mkwst>
So I need to do some work (or find someone to do some work).

[23:55:16.0000] <mkwst>
I don't really want to put up a doc that says "DO X!" if I don't know how to do X in the browser I'm responsible for. :)

[23:55:29.0000] <mkwst>
That's what I mean by "empty document". A spec without code is fairly worthless.

[00:03:51.0000] <annevk>
mkwst: oh, I thought you meant the type of error handling

[00:04:25.0000] <mkwst>
Yeah, sorry. I wasn't clear.

[00:09:44.0000] <annevk>
By the way, there's an intern spot to be filled for the HTML Standard: https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21

[00:10:10.0000] <annevk>
And also somewhat relevant to the WHATWG, folks can work on implementing Fetch in Servo: https://wiki.mozilla.org/Outreachy/2016/December_to_March#Servo:_Complete_implementation_of_Fetch_standard

[01:23:23.0000] <philipj>
Ms2ger: there?

[01:45:50.0000] <philipj>
Ms2ger: It looks like idlharness.js doesn't try to pass null or invalid types to methods in order to check if they'll throw TypeError, is that right or am I doing it wrong?

[01:46:39.0000] <Ms2ger>
That sounds plausible

[01:47:08.0000] <Ms2ger>
In general, "invalid type" is somewhat difficult to construct

[01:50:36.0000] <philipj>
Ms2ger: for interface types that are not nullable, passing in null would be nice

[01:50:49.0000] <Ms2ger>
Agreed

[01:51:08.0000] <Ms2ger>
There's also overloads, unfortunately

[01:51:09.0000] <philipj>
and I guess there are no types that are both instanceof Document and instanceof Window, so one could always use one of those?

[01:51:22.0000] <philipj>
oh, right

[01:52:51.0000] <philipj>
yeah, whatever the implementation of giveMeAnInvalidType() is, it should be possible to write an interface that defeats it

[01:56:17.0000] <philipj>
Ms2ger: is there somewhere I could file an issue for the simple null case that has a non-zero chance of being fixed?

[01:56:55.0000] <philipj>
I'm trying to answer a question for someone else, so I'm not excited about fixing it myself today :)

[02:45:21.0000] <Ms2ger>
philipj, testharness.js repo, I sometimes look at it :0

[02:45:42.0000] <philipj>
Ms2ger: ok :)

[03:21:10.0000] <SteveF_>
Domenic: pinged you on twitter (then realised I am persona non grata [wise move] in your twitterverse) so leaving here Script-Based Web Accessibility proposal https://github.com/cyns/wapa/blob/master/ScriptAccessibility.md#script-based-web-accessibility

[04:05:35.0000] <annevk>
mkwst: this whole modularizing CSP seems like a Process hack and I suspect will only cause you pain due to the shifting dependencies and requirements over time

[04:11:59.0000] <annevk>
mkwst: this is basically what's wrong with the way the W3C works, you start optimizing for producing RECs and as a result you create a disaster for everyone else trying to follow along

[04:37:27.0000] <mkwst>
annevk: Eh. I understand that critique, and I agree to an extent.

[04:38:08.0000] <mkwst>
annevk: However: 1. Beyond W3C process, I think separate documents will give folks like Microsoft the ability to say they implemented a thing without blocking on implementing everything.

[04:39:09.0000] <mkwst>
annevk: 2. Directives are already modular to a great extent. There's no particular reason that `upgrade-insecure-requests` needs to be in the same document as `sandbox`. They do completely divergent things, and are only in the same document because of the delivery mechanism.

[04:39:59.0000] <mkwst>
annevk: 3. Separate documents allow more explanation. I think the cookies feature is significantly clearer, both in justification and scope, in a separate, focused document.

[04:45:55.0000] <mkwst>
(In other words, CSP is a generic delivery mechanism for a bunch of stuff. Some of that stuff is similar to some other bits of that stuff, and grouping them together makes sense to me.)

[05:02:13.0000] <annevk>
mkwst: did Microsoft actually say as much? It has never been a problem for them before

[05:02:31.0000] <annevk>
mkwst: see e.g., HTML or URL

[05:02:52.0000] <mkwst>
annevk: No. They've said they aren't prioritizing "CSP2", and have been unresponsive to my (repeated) suggestions that there are important bits and not so important bits.

[05:03:25.0000] <annevk>
mkwst: right, I don't think splitting will change that

[05:05:25.0000] <mkwst>
annevk: I'm not suggesting that it solves the problem. I think it makes the problem smaller.

[05:06:50.0000] <Ms2ger>
It makes the problem bigger, because now they have a dozen specs they can ignore

[05:08:53.0000] <mkwst>
If the specs are smaller, implementing them is easier, which means they can tick a nice feature checkbox. That's appealing.

[05:09:26.0000] <mkwst>
(also, annevk: if you haven't already, tell me I'm an idiot on the mailing list. :) )

[05:11:09.0000] <jgraham>
I'm unconvinced that smaller specs are easier to implement

[05:11:27.0000] <jgraham>
depending on how they became "smaller"

[05:12:07.0000] <jgraham>
Like, one way to make small specs is to specify features in isolation and conveniently ignore the interaction between that feature and other features

[05:12:23.0000] <jgraham>
So things look small but actually they aren't

[05:12:32.0000] <philipj>
annevk: when merging PRs that need a new ack, do you think we should just change the commit, or do a separate "ack for previous commit" thing?

[05:12:33.0000] <jgraham>
They're just underspecified

[05:12:34.0000] <annevk>
mkwst: I've made the point that the W3C Process has detrimental effects on everyone but lawyers enough times

[05:12:44.0000] <jgraham>
(*cough* web-performance *cough*)

[05:12:49.0000] <annevk>
philipj: I think we should change the commit and override with --author

[05:13:10.0000] <mkwst>
annevk: If you can invent a world in which lawyers don't matter, I'm totally happy to join you there.

[05:13:18.0000] <philipj>
annevk: you mean preserve the original author, or to pretend that we are the authors of the fix too?

[05:13:27.0000] <annevk>
philipj: preserve

[05:13:40.0000] <annevk>
mkwst: you're already here

[05:13:50.0000] <philipj>
annevk: right, that's what git commit --amend does by default

[05:13:55.0000] <mkwst>
...

[05:14:09.0000] <annevk>
:-P

[05:14:32.0000] <annevk>
philipj: so whenever I use git commit --amend I can modify the commit message, but not the commit itself

[05:14:45.0000] <philipj>
annevk: you need to git add -p first

[05:15:10.0000] <philipj>
or any kind of git add, -A would do as well

[05:15:20.0000] <annevk>
philipj: so make a change, use git add -p, then do git commit --amend?

[05:15:24.0000] <philipj>
annevk: yep

[05:15:40.0000] <annevk>
philipj: thanks, that should make things easier

[05:15:46.0000] <philipj>
annevk: :)

[05:15:57.0000] <annevk>
philipj: I usually fiddle around a bit with the GitHub GUI which is not really ideal, but I managed to get the same effect in the end

[05:16:04.0000] <jgraham>
mkwst: So the flip side of the lawyer coin is that if no one had done HTML5 because W3C dropped it and WHATWG weren't lawyer-friendly then, well, that world would be a worse world than this one. So it's empirically true that it is possible to worry too much about the problems with doing work and not enough about the problems of not doing work.

[05:17:25.0000] <mkwst>
jgraham: Put the lawyer stuff to the side. My problem at the moment is that the work I'm doing is helping Chrome users, and Firefox users to an extent, but isn't helping anyone else (and, due to that lag, isn't helping Chrome users as much as it should).

[05:17:39.0000] <mkwst>
jgraham: I'm looking for solutions to that problem.

[05:18:08.0000] <jgraham>
Well, I don't know of a way to force Microsoft to implement something :|

[05:18:21.0000] <mkwst>
Or Apple. Or Mozilla.

[05:18:31.0000] <mkwst>
Forcing is the wrong question, I think.

[05:18:36.0000] <mkwst>
I want to make things appealing to implement.

[05:19:10.0000] <jgraham>
I think things are appealing to implement if they solve real problems that users are percived to have

[05:19:36.0000] <jgraham>
I suspect the way the spec is structured is a correction to that

[05:20:03.0000] <mkwst>
I think splitting things out makes individual improvements clearer, yes.

[05:21:00.0000] <mkwst>
https://w3c.github.io/webappsec/specs/csp-cookies/ is a tiny spec that (tries to) identify a specific problem, and proposes a specific solution. It delivers that solution in terms of CSP. *shrug* That seems like a clear package.

[05:21:22.0000] <mkwst>
(With the usual strawman, rough draft, etc. caveats. Assume I spent time to polish things.)

[05:22:27.0000] <annevk>
I've never know the presentation of a specification to be what convinces Apple and/or Microsoft

[05:22:47.0000] <annevk>
What matters is developers requesting the functionality and the popularity of the features

[05:23:18.0000] <annevk>
That's why Microsoft eventually caved and implemented CORS for XMLHttpRequest, and dropped XDomainRequest

[05:27:24.0000] <Domenic>
SteveF_: oh cool, will take a look... and should probably unblock you, I just remember blocking you after you said something about cocks in response to one of my tweets

[06:48:30.0000] <annevk>
Hmm, more magic in HTML

[06:48:45.0000] <annevk>
Discard tasks. If anything got discarded, do x.

[06:57:46.0000] <SteveF_>
Domenic: sorry can't remember tweeting "about cocks in response to one of my tweets", but will make an effort not to tweet such stuff to you in future.

[07:52:22.0000] <annevk>
Domenic: could you give https://github.com/whatwg/html/pull/203 a final pass?

[07:53:04.0000] <Domenic>
annevk: will do

[08:09:29.0000] <annevk>
Domenic: ah thank you for catching that

[08:09:35.0000] <annevk>
Domenic: it seems the parser does not choke on typos

[08:10:52.0000] <Domenic>
annevk: yeah I figured this one would need a review of the built product

[08:54:34.0000] <annevk>
Domenic: pushed the changes you wanted

[08:54:44.0000] <annevk>
Domenic: I think HTMLAllCollection should just become its own class

[08:54:57.0000] <Domenic>
annevk: reviewing built output now

[08:55:08.0000] <Domenic>
annevk: that seems probably true, although we should investigate in a follow-up bug

[08:55:18.0000] <annevk>
Domenic: although perhaps someone could quickly peek at the Chromium code for HTMLAllCollection whether that is true there too

[08:55:22.0000] <annevk>
Domenic: will file an issue

[16:30:51.0000] <MikeSmith>
anybody else having a problem with gmail currently not loading in Canary (on OS X at least)?

[16:31:00.0000] <MikeSmith>
and if so, know any workaround

[16:31:08.0000] <MikeSmith>
it hasn't been working for me for days now


2015-09-30
[22:32:37.0000] <annevk>
MikeSmith: FirefoxNightly

[22:45:27.0000] <MikeSmith>
annevk: yeah already running Nightly too

[23:09:00.0000] <mkwst>
MikeSmith: File a bug at https://crbug.com/new and ping me the ID?

[00:54:49.0000] <Ms2ger>
Remember when Microsoft would never submit feedback unless we'd publish a fork at w3c? https://github.com/whatwg/html/issues/210#issuecomment-144211444

[00:55:39.0000] <MikeSmith>
mkwst: seems it's https://code.google.com/p/chromium/issues/detail?id=537360

[00:56:13.0000] <MikeSmith>
mkwst: chatted with scottmg about it a bit a few hours earlier

[00:57:16.0000] <mkwst>
MikeSmith: Does https://code.google.com/p/chromium/issues/detail?id=537437 help? e.g. make sure that chrome://flags/#enable-javascript-harmony is disabled?

[00:57:29.0000] <mkwst>
/me turns #whatwg into a Chrome support channel.

[00:59:07.0000] <MikeSmith>
heh

[00:59:10.0000] <MikeSmith>
yeah I

[00:59:21.0000] <MikeSmith>
I'm posting a comment there now

[00:59:37.0000] <MikeSmith>
the problem in fact goes away if I disable chrome://flags/#enable-javascript-harmony

[01:07:32.0000] <mkwst>
Wunderbar! Solved! /me closes the bug

[01:10:30.0000] <mkwst>
The V8 folks sit right behind me. I'll poke them.

[02:03:53.0000] <MikeSmith>
mkwst: cheers

[03:31:50.0000] <Vritika>
Hello!...,  I am Vritika Soni.  I am interested in Outreach Program(Outreachy). I found Mozilla organization and I would like to work on its project. I am a newbie so I need guidance in this program.

[03:34:47.0000] <Ms2ger>
Alright, first lesson: stay connected to IRC until someone answers your question

[03:36:13.0000] <ondras_>
:-)

[03:36:44.0000] <jgraham>
Or at least until someone *reads* your question

[03:50:38.0000] <MikeSmith>
mkwst: is much happening with Entry Point Regulation since last year?

[03:51:05.0000] <MikeSmith>
anybody working on implementing it other than the extension that was developed?

[03:51:17.0000] <mkwst>
MikeSmith: We published a draft in June (http://www.w3.org/TR/epr/).

[03:51:43.0000] <mkwst>
MikeSmith: We haven't prioritized it in Chrome, but I know Google's infrastructure security team wants it.

[03:52:13.0000] <mkwst>
MikeSmith: It will bubble back up in Q1, probably. Last I heard, David was working on a Service Worker-based polyfill.

[03:55:18.0000] <MikeSmith>
mkwst: OK, thanks

[03:55:36.0000] <mkwst>
MikeSmith: Why do you ask? :)

[03:56:18.0000] <MikeSmith>
just showed up on my github radar due to Wendy creating a new repo for it

[03:56:50.0000] <MikeSmith>
and then when I saw the notification I recalled that I hadn't heard much more about since the time when David introduced it last year or so

[04:03:57.0000] <mkwst>
MikeSmith: Ah. Right. I'm splitting webappsec into a bajillion repositories. No normative change. :)

[04:05:25.0000] <MikeSmith>
mkwst: coolーyeah, I support the move to multiple repos 🍻

[04:06:01.0000] <MikeSmith>
*decision to move to multiple repos

[04:53:40.0000] <annevk>
https://www.google.com/#q=spec.whatwg.org Where does Google gets it weird metadata from?

[04:53:50.0000] <annevk>
"XHR spec"

[04:53:53.0000] <annevk>
"WhatWG"

[04:54:14.0000] <annevk>
"WHATWG: Living HTML - HTML Standard"

[07:06:55.0000] <ondras>
annevk: please, is space allowed in path of <img src="... ..." /> ?

[07:07:09.0000] <ondras>
(src being http://stuff)

[07:07:25.0000] <annevk>
ondras: spaces are not allowed in URLs

[07:08:29.0000] <ondras>
annevk: okay, also řšž are to be percent-encoded even inside a quoted src attribute?

[07:08:44.0000] <ondras>
(percent-encoded utf-8 bytes, more precisely)

[07:10:02.0000] <annevk>
ondras: no you can use those

[07:10:09.0000] <annevk>
ondras: just make sure everything is utf-8

[07:10:22.0000] <annevk>
ondras: and expect percent-encoded bytes in JavaScript and on the server

[07:12:14.0000] <ondras>
annevk: okay, interesting. Firefox apparently silently converts space to %20 when parsing the img src

[07:12:35.0000] <ondras>
hm, other browsers as well

[07:18:35.0000] <annevk>
ondras: sure, everyone does that

[07:18:43.0000] <annevk>
ondras: also mandated by the URL standard :-)

[07:18:59.0000] <annevk>
ondras: it's just a conformance error since it makes the URL less portable

[07:22:07.0000] <annevk>
The amount of confusion around SOP is too damn high

[07:22:11.0000] <annevk>
Latest victim https://twitter.com/aerotwist/status/649214802305417216

[07:22:37.0000] <annevk>
Which was reviewed by mkwst and several others of Chrome security no less

[07:23:05.0000] <mkwst>
Hrm? I think you might have misunderstood hjs point.

[07:23:39.0000] <mkwst>
He wants to access insecure podcast data from a secure page. He can't.

[07:24:02.0000] <mkwst>
He wants to access cross-origin podcast data from podcasters who don't serve CORS headers. He can't.

[07:24:39.0000] <mkwst>
A proxy would allow him to do so, but he outlines some reasons that proxies are a bad idea.

[07:25:34.0000] <mkwst>
He's bummed that a combination of SOP and MIX (both of which he suggests are good in and of themselves) stop him from building the thing he wants to build without a proxy. *shrug*

[07:25:36.0000] <Ms2ger>
I don't want him to access my private podcasts

[07:25:43.0000] <annevk>
mkwst: he also says that a proxy shouldn't have access without CORS

[07:25:48.0000] <annevk>
mkwst: which is just wrong

[07:25:59.0000] <annevk>
mkwst: perhaps you didn't read the “How About a Big Proxy?” section?

[07:26:03.0000] <mkwst>
annevk: If he said that, I missed it when I talked with him.

[07:26:21.0000] <annevk>
mkwst: I mean I understand this problem

[07:26:24.0000] <annevk>
mkwst: I wrote about it

[07:26:37.0000] <annevk>
mkwst: I just don't understand the assertion about proxies and CORS

[07:27:24.0000] <mkwst>
annevk: Yes. I agree with you that "if the resource is delivered over HTTPS and without the CORS header, the proxy won’t be able to access it on behalf of the client" seems wrong.

[07:27:38.0000] <mkwst>
annevk: I don't see that as the crux of the article. :)

[07:28:09.0000] <annevk>
mkwst: I mean the rest of the article was already known

[07:28:15.0000] <annevk>
mkwst: and this new assertion is false

[07:28:26.0000] <annevk>
mkwst: hopefully it gets more folks to think about the problem

[07:28:31.0000] <mkwst>
*shrug* I don't see the new assertion as the important part. :)

[07:28:34.0000] <annevk>
mkwst: and hopefully he'll clarify that statement

[07:34:43.0000] <jochen__>
annevk: is there something like a 'loading principal' and 'triggering principal' in spec language?

[07:34:58.0000] <jochen__>
annevk: apparently these are concepts in firefox

[07:41:49.0000] <annevk>
jochen__: I think request's client is somewhat close to triggering

[07:42:07.0000] <annevk>
jochen__: not sure about loading

[07:42:16.0000] <annevk>
jochen__: I haven't really found a need for them

[07:42:22.0000] <jochen__>
hum

[07:42:30.0000] <jochen__>
so I'm asking because the referrer thing

[07:42:47.0000] <jochen__>
if a document includes a cross origin css file that in turn references an image

[07:43:00.0000] <jochen__>
both chrome and firefox will use the css file's url as basis for the referrer for the load of the image

[07:43:01.0000] <annevk>
jochen__: Gecko has some stuff they expose through those just for extensions and privileged code that would be hard to match, but we don't write specs for those

[07:43:21.0000] <jochen__>
now the question is what kind of term can I use to describe this situation in the referrer spec short of adding an exception for css documents?

[07:43:27.0000] <annevk>
jochen__: the way that should work is that CSS should get its Fetch act together and define the referrer for their fetches

[07:43:57.0000] <annevk>
jochen__: when they define the referrer, they can just set it to the URL of the CSS resource if it's an external resource and leave it as "client" when it's inline

[07:44:31.0000] <annevk>
jochen__: I guess you could add a warning that CSS (and SVG) haven't defined Fetch integration yet

[07:44:37.0000] <annevk>
jochen__: numerous things are therefore unclear

[07:44:53.0000] <jochen__>
so the referrer spec always uses the current 'incumbent settings object' as source for the referrer

[07:45:05.0000] <jochen__>
would that be the svg document once they got this sorted out?

[07:45:25.0000] <annevk>
jochen__: the referrer spec should use request's client, no?

[07:45:46.0000] <annevk>
jochen__: for SVG documents, yeah, it'll be the same as HTML documents

[07:45:58.0000] <annevk>
jochen__: and SVG images cannot fetch external resources so don't matter

[07:46:10.0000] <jochen__>
ehrm, i meant css

[07:46:38.0000] <jochen__>
i guess i'll just add an explicit section CSS documents

[07:46:57.0000] <annevk>
jochen__: for CSS what happens is that CSS sets referrer to a URL

[07:47:11.0000] <annevk>
jochen__: so you get an explicit URL that you then modify as you see fit

[07:47:20.0000] <annevk>
jochen__: no settings objects involved

[07:51:55.0000] <jochen__>
well, somewhere the url has to come from

[07:52:02.0000] <jochen__>
at least in chrome it comes from the css parser context

[07:52:12.0000] <jochen__>
which in turn gets it from some document

[07:52:25.0000] <annevk>
jochen__: I see

[07:53:29.0000] <annevk>
jochen__: well yes, some document fetches a CSS resource, then feeds that response to CSS along with sufficient other data, CSS then should do the rest, e.g., take the url from the response and use that as base URL and referrer

[07:54:05.0000] <jochen__>
is there a spec text for that?

[07:54:20.0000] <annevk>
jochen__: see above where I mentioned that CSS does not really have its act together

[07:54:32.0000] <jochen__>
well, they don't use fetch

[07:54:43.0000] <jochen__>
but there should be something that says how to load css images and fonts, no?

[07:54:58.0000] <annevk>
They don't really use anything, but if you were to take that literally CSS wouldn't use service workers either, etc.

[07:55:14.0000] <annevk>
CSS of course uses something, and everyone knows it's Fetch, it's just not written down

[07:55:25.0000] <annevk>
So theoretically a ton of stuff breaks and the theory should really be fixed

[07:55:31.0000] <annevk>
But in practice everyone has managed to deal

[07:56:15.0000] <jochen__>
sooo

[07:56:41.0000] <jochen__>
i'll add some text to the referrer spec that says "css should make sure it uses the referrer policy from whereever it felt like getting the referrer from in the first place"

[07:57:52.0000] <annevk>
It seems very reasonable to add a warning or even try to explain how it should work

[08:24:00.0000] <Domenic>
annevk: did you start https://github.com/whatwg/html/issues/210 yet or shall I

[08:26:09.0000] <parul>
Hello

[08:28:16.0000] <parul>
i am interested in mozilla "visual design with research data" project.please inform me the irc channel for it.

[08:28:57.0000] <parul>
so I will start contributing for it.

[08:35:10.0000] <annevk>
Domenic: I haven't

[08:35:25.0000] <Domenic>
annevk: k, taking it

[08:35:36.0000] <annevk>
Domenic: I've been meaning to do some more Fetch stuff, but I keep getting distracted

[08:36:04.0000] <annevk>
parul: hey, I'm not familiar with that project

[08:36:06.0000] <Domenic>
annevk: do more URL stuff!

[08:36:13.0000] <annevk>
parul: do you know who's responsible?

[08:37:02.0000] <parul>
annevk: no I don't know who is the mentor of this project

[08:37:33.0000] <annevk>
parul: from the wiki page it seems like you want to ping ilana on irc.mozilla.org

[08:38:33.0000] <annevk>
parul: assuming you were asking about https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data

[08:38:38.0000] <parul>
annevk:I get the info of this project from this link https://wiki.mozilla.org/Outreachy/2016/December_to_March

[08:39:09.0000] <annevk>
parul: yeah, this IRC channel is only for "Contribute to the HTML Standard!"

[08:39:32.0000] <annevk>
(from those projects, anyway)

[08:39:48.0000] <parul>
annevk: irc channels,mentors and the mailing list is not mention there.

[08:39:55.0000] <annevk>
Domenic: yeah, I've blocked on that since the base URL thing is still a bit unclear

[08:40:02.0000] <annevk>
Domenic: I guess I should update some issue

[08:40:25.0000] <annevk>
parul: it says "Mentor: Ilana Segall", no?

[08:40:52.0000] <annevk>
parul: and if you click that name an IRC nickname is suggested, and I can tell that person is active on irc.mozilla.org

[08:42:38.0000] <parul>
annevk: well fine, sorry my mistake

[08:42:50.0000] <annevk>
parul: no worries, happy to help

[08:43:09.0000] <parul>
annevk: okey

[08:50:02.0000] <annevk>
Domenic: in particular, I was thinking that a base URL change thingie which is needed for :visited would help

[08:50:20.0000] <annevk>
Domenic: but then I realized it wouldn't do any good for elements not currently in the document

[08:50:38.0000] <annevk>
Domenic: so I guess we still need to define the base URL updating on the getter thingie...

[08:51:01.0000] <annevk>
Domenic: but also have this base URL change thing...

[08:51:20.0000] <Domenic>
annevk: yeah, seems likely... :-/

[08:51:30.0000] <annevk>
Domenic: or would it be better to just have the base URL change thing, but somehow iterate over all elements whose node document is the document

[08:52:03.0000] <Domenic>
annevk: I think doing the lazy thing mostly, and having the base URL change thing be a special thing for CSS, makes a lot of sense. matches implementations, and makes the weird thing special-cased.

[08:52:17.0000] <annevk>
Domenic: I doubt that matches Gecko

[08:52:33.0000] <annevk>
Domenic: and it's not a big bone for custom elements either

[08:52:49.0000] <Domenic>
annevk: really? it seems like the only sane implementation strategy.

[08:53:17.0000] <annevk>
Domenic: because it's impossible to notify elements not in a document?

[08:54:02.0000] <Domenic>
annevk: not impossible, but a lot more work to keep track of them all, and slower (although I guess changing base URLs should not happen that often).

[08:54:38.0000] <Domenic>
annevk: and if everything else is lazy (because get the input wants to happen lazily), it only makes sense to do the same for base

[08:55:00.0000] <annevk>
Domenic: I guess I'm somewhat convinced with the lazy approach since base URL changes in general are just a really bad idea

[08:58:31.0000] <annevk>
Domenic: thanks for reminding me and talking through this, needed that

[09:01:52.0000] <Domenic>
:)

[09:42:16.0000] <annevk>
HTML has 121 closed PRs already

[09:42:46.0000] <annevk>
Is that about 4 a day or am I misrepresenting when we started?

[09:50:12.0000] <zcorpan>
philipj: i think bugzilla bugs should be RESOLVED MOVED when there's a PR

[09:59:28.0000] <Domenic>
annevk: looks like we started about August 26-27

[09:59:36.0000] <Domenic>
so... yeah

[10:07:39.0000] <zcorpan>
time for a new REC?

[11:58:07.0000] <wanderview>
cool to see edge bugs referenced in whatwg github issues... if only they were links

[12:02:48.0000] <Domenic>
baby steps ^_^

[12:03:40.0000] <Domenic>
grrr, why didn't i write the streams tests in web-platform-tests format the first time around...

[12:04:09.0000] <Domenic>
do people know the best pattern for a test that should run the same in both workers and window?

[12:05:11.0000] <Domenic>
Maybe it is something like this https://github.com/domenic/unhandled-rejections-browser-spec/blob/master/tests/promise-rejection-events.html

[12:05:35.0000] <gsnedders>
Hah, I remember people questioning why Opera bugs occasionally got referenced, given the lack of access.

[12:06:05.0000] <gsnedders>
Domenic: that's more or less what i'd suggest

[12:06:25.0000] <Domenic>
gsnedders: would be sweet if I could avoid generating that .html file manually for each test, somehow.

[12:07:53.0000] <gsnedders>
Domenic: too quickly gets into magic, IMO

[12:08:10.0000] <Domenic>
meh, don't really know

[12:15:18.0000] <Domenic>
gsnedders: so this service_worker_test seems to be a blink-specific thing... any thoughts on how I should test in service workers?

[12:16:51.0000] <wanderview>
Domenic: I think best worker/window approach is to make a .js file that gets run in both cases... in worker context you make a shim for asserts that proxies back to main thread

[12:17:00.0000] <wanderview>
not sure that has been done yet for wpt anywhere yet

[12:17:04.0000] <gsnedders>
Domenic: No.

[12:17:19.0000] <gsnedders>
Domenic: I know next to nothing about service workers :)

[12:18:03.0000] <wanderview>
Domenic: service_worker_test() should be in upstream wpt

[12:18:30.0000] <Domenic>
Ah, I found it, yeah. https://github.com/w3c/web-platform-tests/blob/e5e8fb9ebc4d5b2220abff5679fa0781c01f2c05/service-workers/service-workers/resources/test-helpers.js

[12:18:39.0000] <wanderview>
yea

[12:19:36.0000] <wanderview>
Domenic: one complaint we have about a lot of the current wpt tests that involve workers... they tend to be all or nothing... not broken up into separate test cases so we can't mark the one thing we don't implement yet as EXPECTED_FAIL

[12:19:57.0000] <wanderview>
Domenic: thanks for writing wpt tests, though

[12:20:29.0000] <Domenic>
wanderview: I plan to write lots of test cases in each file, then use a .html file that runs that file in all four types of workers...

[12:20:34.0000] <Domenic>
wanderview: will get your review

[12:20:39.0000] <wanderview>
cool

[12:20:43.0000] <wanderview>
r+

[12:21:34.0000] <annevk>
TabAtkins: the way <input type> defaulting works is extremely common among most (if not all) enumerated attributes

[12:21:45.0000] <annevk>
TabAtkins: if custom elements would not match that they would be weird

[12:22:17.0000] <TabAtkins>
annevk: I don't think it's a good idea for custom elements to match, honestly.  enum properties work differently, CSS properties work differently, etc.

[12:23:05.0000] <TabAtkins>
enum attributes are just weird, and matching the platform as we add new ones to HTML is fine, but I would not match that in a custom element.

[12:23:48.0000] <annevk>
I totally would. Changing the attribute is actually what's completely alien

[12:24:12.0000] <annevk>
Parsing the attribute and based on that potentially changing the default state is much more logical

[12:31:31.0000] <zcorpan>
TabAtkins: html (and xml languages too) accept any value for attributes generally

[12:32:28.0000] <TabAtkins>
There's no way for CSS to expose a *generic* mechanism addressing the issue, tho.  At best it can do something host-language specific, so that browsers hide the complexity of the big selector in their selector matching code instead.

[12:32:55.0000] <TabAtkins>
zcorpan: Sure. But there's nothing requiring the attribute to *stay* the value it's set to, in the presence of JS.

[12:34:20.0000] <zcorpan>
TabAtkins: maybe so, but JS does not need to be involved for this problem to appear, so it's a bit moot point :-)

[12:35:11.0000] <TabAtkins>
Right, the problem is that you can't define what set of keywords an enumerated attribute accepts.  I'm saying that, in the presence of JS, you can fix that (and imo should for your custom elements).

[12:37:38.0000] <zcorpan>
:input-type(newtype) would also let you style the control differently only in UAs that support "newtype"

[12:38:50.0000] <TabAtkins>
Yeah.  It's just a specialized "only for <input type>" mechanism.

[12:39:45.0000] <zcorpan>
/me awaits csswg members to Genericalize it so it can apply to Other Host Languages as well

[12:45:29.0000] <TabAtkins>
Like I just said, we can't.

[12:45:51.0000] <TabAtkins>
/me is unsure at what level of sarcasm zcorpan is operating.

[12:46:27.0000] <zcorpan>
i can include the end tag for you: </sarcasm>

[12:47:15.0000] <TabAtkins>
What I meant is that <input type> is not the only enumerated attribute with this behavior, and probably not the only enumerated attribute that wants to have UA-default styles based on itself.

[12:48:56.0000] <tantek>
The SARCASM Host Language needs no end tag.

[12:50:58.0000] <gsnedders>
zcorpan: I'm struggle to infer the open tag

[12:51:51.0000] <zcorpan>
gsnedders: i can write you a DTD if you send me chocolate

[12:54:20.0000] <gsnedders>
zcorpan: hah, you admit British chocolate is better? ;P

[12:54:42.0000] <TabAtkins>
zcorpan: And without some form of "generic-ness", then specifying the pseudo-class is just moving the complexity from the UA stylesheet to the UA's selector definition.  It doesn't improve the brittleness/verbosity; either way you have a list of values that need to be maintained.

[12:55:29.0000] <zcorpan>
TabAtkins: <button type>, <menu type>... i think there's not much more in html that makes sense to style differently based on an enum attribute

[12:56:09.0000] <TabAtkins>
The benefits to authors are that (a) they can then use rando values in their own page and still match them as :input-type(text), which seems low value, and (b) they can use new types and match them with :input-type(new) if they're supported (but if they're not, they'll get caught by :input-type(text), so I'm unsure in practice of the usefulness of that).

[12:56:38.0000] <zcorpan>
gsnedders: i'll know it when i get it :-)

[12:56:44.0000] <gsnedders>
zcorpan: :)

[12:58:32.0000] <zcorpan>
TabAtkins: it seems useful to me to have :input-type(text) match unsupported types. why would you not want to style them as other regular text fields, assuming you don't polyfill them to something else?

[12:58:57.0000] <TabAtkins>
I dunno!

[12:59:02.0000] <JonathanNeal>
What’s this? :input(text) selector?

[12:59:13.0000] <zcorpan>
JonathanNeal: CSS7!!

[12:59:59.0000] <zcorpan>
<http://www.w3.org/mid/CAAWBYDCzcZ4dpNw3gjWnYrTOqN2UbSCKcYoGG7RSytHju8moqw⊙mgc>

[13:00:45.0000] <JonathanNeal>
Neat.

[13:01:36.0000] <TabAtkins>
zcorpan: (Note that, as I said in the email, I'm not opposed to :input-type(), I just don't currently believe this problem is sufficiently worthwhile to address with new syntax.)

[13:01:49.0000] <JonathanNeal>
Neat. Like :input(text) => input:not([type]), input[type="text"] ?

[13:02:15.0000] <TabAtkins>
JonathanNeal: Also input:not([type=password]):not([type=tel])...

[13:02:25.0000] <TabAtkins>
Because <input type=foo> is a text input.

[13:03:37.0000] <TabAtkins>
Rather, it's explictly equivalent to `input:not([type]), input[type]:not([type=password])...`

[13:06:02.0000] <TabAtkins>
As an idle thought, a genericization would probably look like a switch statement...

[13:12:40.0000] <Domenic>
I am not really opposed to input:not([type=password i]):.......

[13:12:46.0000] <Domenic>
it's ugly but for UA stylesheets it should be fine

[13:12:54.0000] <Domenic>
it's not like we're going to add new input types soon

[13:15:00.0000] <gsnedders>
case insensitive?

[13:15:16.0000] <Domenic>
yes, <input type="PASSWORD"> is still a password

[13:32:07.0000] <tobie>
TabAtkins: does Bikeshed have a mechanism to include the content of external resources similar to: https://www.w3.org/respec/ref.html#data-include ?

[13:32:18.0000] <TabAtkins>
Not currently.

[13:32:42.0000] <tobie>
How could you even process that information so quickly?

[13:32:56.0000] <TabAtkins>
???

[13:33:24.0000] <tobie>
!!!

[13:34:08.0000] <tobie>
/me had a long day.

[13:34:22.0000] <tobie>
Is this somehow planned?

[13:34:53.0000] <tobie>
Easy/hard given the current architecture?

[13:35:04.0000] <TabAtkins>
It's not currently in my plans, but I'm not opposed.  Feel free to file an issue on me for it.  I'd appreciate some pointers to existing usage of this in ReSpec.

[13:35:21.0000] <tobie>
I'm using it to include code samples of live apps.

[13:40:08.0000] <TabAtkins>
tobie: Why not include it inline?

[13:41:42.0000] <JonathanNeal>
Tangent: [type=password i], in today CSS does this work, are attribute selectors even case-sensitive?

[13:43:37.0000] <tobie>
I have the apps and use case doc in the same repo, like that I don't have any copy-pasting to do.

[13:44:12.0000] <tobie>
Added the links to https://github.com/tabatkins/bikeshed/issues/496

[13:47:38.0000] <robertkowalski>
heya

[13:48:36.0000] <robertkowalski>
i want to start to work on a spec for console.log and friends

[13:48:42.0000] <Domenic>
\o/

[13:49:03.0000] <robertkowalski>
but before i start i was wondering if i need to use a special kind of test framework / test runner

[13:49:05.0000] <TabAtkins>
Didn't somebody already start on that?

[13:49:16.0000] <Domenic>
TabAtkins: yep, and stall

[13:49:31.0000] <TabAtkins>
Right. Maybe it can be reused rather than starting from scratch.

[13:49:45.0000] <Domenic>
robertkowalski: web-platform-tests are the best tests: https://github.com/w3c/web-platform-tests

[13:50:00.0000] <Domenic>
robertkowalski: http://testthewebforward.org/docs/

[13:50:45.0000] <robertkowalski>
cool thank you Domenic

[13:52:47.0000] <tobie>
iirc MikeSmith had a draft of the console API in the Browser Testing and Tools WG

[13:53:07.0000] <tobie>
It's mentioned in the charter but can't seem to find it online.

[13:53:28.0000] <TabAtkins>
tobie: That makes sense.

[13:53:47.0000] <TabAtkins>
(re: using examples in both explainer and spec)

[13:53:51.0000] <TabAtkins>
File an issue on me?

[13:54:07.0000] <tobie>
https://github.com/tabatkins/bikeshed/issues/496

[13:54:12.0000] <TabAtkins>
danke

[13:57:26.0000] <MikeSmith>
philipj (or anybody) about the 0.03% threshold of usage-counter data for blink intent-to-deprecate features, what does that work out as far as number of sites? (I mean the number within whatever sample the usage-counter data is collected from)

[13:58:05.0000] <tobie>
robertkowalski: found this: http://sideshowbarker.github.io/console-spec/

[13:58:05.0000] <MikeSmith>
and it is sites, right? not URLs/documents

[13:58:23.0000] <MikeSmith>
yeah that doc is quite imcomplete

[13:58:52.0000] <MikeSmith>
the best resource for console still remains http://getfirebug.com/wiki/index.php/Console_API

[13:58:53.0000] <philipj>
MikeSmith: Chrome's data is percentage of page views, so it can't be compared with number of sites in a corpus like httparchive

[13:59:14.0000] <MikeSmith>
philipj: ah OK, makes sense

[13:59:48.0000] <philipj>
MikeSmith: it's quite likely that there are some counters with high usage only due to youtube.com or similar

[14:00:00.0000] <MikeSmith>
ah

[14:00:34.0000] <philipj>
zcorpan: oh, right, should I fix the two that I've closed?

[14:00:51.0000] <zcorpan>
philipj: naw

[14:02:11.0000] <MikeSmith>
tobie: robertkowalski https://github.com/DeveloperToolsWG/console-object/blob/master/api.md is good

[14:02:37.0000] <MikeSmith>
and https://developer.mozilla.org/en-US/docs/Web/API/Console

[14:07:25.0000] <tobie>
TabAtkins: I'm having a hard time getting em-dashes to work. Shouldn't https://github.com/w3c/sensors/blob/gh-pages/index.bs#L119 so it?

[14:07:55.0000] <TabAtkins>
Assuming there's no spaces at the ends of those lines, yes, it should.

[14:08:32.0000] <tobie>
there isn't.

[14:09:36.0000] <TabAtkins>
Hmmm, it is indeed not working.  Will look.

[14:10:28.0000] <tobie>
ty

[14:11:27.0000] <tobie>
I kind of cargo-culted the boilerplate metadata, so I might be doing something dumb there.

[14:13:28.0000] <TabAtkins>
tobie: Nope, it was a dumb thing on my part.

[14:13:46.0000] <TabAtkins>
Accidentally required the following line to start with whitespace for the emdash conversion to happen.

[14:14:06.0000] <TabAtkins>
Just pushed the fix.

[14:14:13.0000] <tobie>
oh, cool.

[14:14:31.0000] <TabAtkins>
(My specs tend to indent the text, to make headings more obvious on a quick scan, so i didn't notice the problem.

[14:14:33.0000] <TabAtkins>
)

[14:15:41.0000] <tobie>
Yeah, I got used to sticking everything as far left as possible to avoid weird markdown bugs.

[14:16:14.0000] <TabAtkins>
I don't (and won't) implement the "indent means code block" part of Markdown, so feel free to indent.

[14:16:28.0000] <tobie>
Mind pulling in https://github.com/tabatkins/bikeshed/pull/493 while you're at it?

[14:16:57.0000] <tobie>
Oh, you're planning to cherry-pick markdown. Sounds fun.

[14:17:05.0000] <tobie>
CommonMark-- ?

[14:17:17.0000] <tobie>
:P

[14:18:49.0000] <tobie>
TabAtkins: I had added support for that in Respec https://github.com/w3c/respec/blob/develop/js/core/markdown.js#L141-L183

[14:19:20.0000] <tobie>
But it still acted weird on occasion. Or at least I feared it would.

[14:19:41.0000] <TabAtkins>
Yeah, Bikeshed's markdown handles HTML nesting properly.  Indented code is fundamentally incompatible with that.

[14:22:38.0000] <tobie>
I'm not sure what you mean by "Bikeshed's markdown handles HTML nesting properly."

[14:23:07.0000] <TabAtkins>
Bikeshed intermixes HTML and Markdown in a sane way, I mean.

[14:25:43.0000] <tobie>
yeah. Regular markdown certainly doesn't.

[14:26:21.0000] <TabAtkins>
Largely because of the historical mistake of indented code blocks. ^_^

[14:26:44.0000] <TabAtkins>
So yeah, I'm gradually approaching consistency with CommonMark except for that point.

[14:27:34.0000] <TabAtkins>
(Unsure if I'll ever fully implement CommonMark's multi-line backtick semantics, tho. They require some weird back-and-forth integration between parser levels.)

[14:36:10.0000] <robertkowalski>
MikeSmith: oh btw why did you stop working on the console api? was it too boring?

[14:40:52.0000] <MikeSmith>
robertkowalski: I can't say I ever really put much work into it. I put it together intending that somebody else might pick up work on it

[14:41:13.0000] <MikeSmith>
but that said it's never been a high priority for me personally

[14:41:32.0000] <MikeSmith>
I guess that's true of others as well

[14:42:09.0000] <MikeSmith>
it's not clear how strong of a need we have for a high level of interoperability around it

[14:42:38.0000] <MikeSmith>
the main reason to have a spec is to ensure we get interoperability among implementations

[14:43:13.0000] <MikeSmith>
and to avoid creating interoperability frustrations for devs

[14:44:18.0000] <MikeSmith>
I could be wrong but I think console interoperability (or lack of) doesn't seem like a pain point for devs currently

[14:44:38.0000] <MikeSmith>
TabAtkins: http://stackoverflow.com/questions/32874967/html5-image-preloading if you have any insights

[14:56:50.0000] <robertkowalski>
MikeSmith: *nod*

[14:57:24.0000] <robertkowalski>
MikeSmith: maybe i'll pick it up. i like to write those spec tests

[14:57:44.0000] <robertkowalski>
i wrote some with another test framework ~1yr ago

[14:58:32.0000] <MikeSmith>
TabAtkins: thanks (would upvote that but I'm out of votes for today until ~1hr or so from now)

[14:59:05.0000] <MikeSmith>
robertkowalski: if you do pick up work on it I would be glad to help with review and such

[14:59:21.0000] <MikeSmith>
but note that terinjokes has been working on something too from time to time

[14:59:51.0000] <MikeSmith>
not sure where he's at with it currently but maybe y'all could collaborate

[15:00:11.0000] <MikeSmith>
robertkowalski: https://github.com/terinjokes/console-spec

[15:00:24.0000] <MikeSmith>
http://terinjokes.github.io/console-spec/

[15:01:05.0000] <MikeSmith>
btw how do we test the console object?

[15:01:31.0000] <MikeSmith>
given that it's not exposed to web content

[15:03:39.0000] <robertkowalski>
in node we could listen on stdout / stderr i guess and regarding browsers i was hoping that http://testthewebforward.org/ would support it in some way

[15:09:29.0000] <MikeSmith>
robertkowalski: yeah the testharness for testtwf runs in-browser strictly in JS, so it has no way to get to console output afaict

[15:10:00.0000] <MikeSmith>
but yeah I had not been thinking about the node.js/io.js context

[15:12:49.0000] <jgraham>
Yeah, you can't test the console method in a cross browser way afaik

[15:12:58.0000] <jgraham>
Unless we start exposing test-only APIs

[15:13:16.0000] <jgraham>
Which has been sugggested, but I am somewhat sceptical about

[15:16:04.0000] <robertkowalski>
could we implement the tests in node and browser vendors could port it into their testsuites?

[15:16:26.0000] <robertkowalski>
feels a bit uncool, but better than nothing i guess

[15:17:22.0000] <gsnedders>
BTW, if anyone has any opinions on what needs sorted out with the CSS testsuite, prod me

[15:22:51.0000] <jgraham>
robertkowalski: I don't see how node helps you here

[15:28:31.0000] <robertkowalski>
jgraham: build the reference testsuite or even reference implementation in node

[15:29:22.0000] <robertkowalski>
jgraham: and hoping others will follow / start helping to make testing in browsers easier :)

[15:30:23.0000] <robertkowalski>
<- specs newbie

[15:43:26.0000] <gsnedders>
robertkowalski: and how do you know the reference implementation is right?

[15:43:31.0000] <Domenic>
robertkowalski: in terms of web tests the most important test will be the stuff that can be observed from scripts (and thus cause potential interop problems)

[15:43:43.0000] <Domenic>
robertkowalski: so e.g. what methods exist on console, and when or if they ever throw errors

[15:44:17.0000] <Domenic>
robertkowalski: the "side effect" of logging to console is less important to test (but, would be nice for devs, so that they know they can use e.g. %s across all browsers and get useful results.)

[15:47:26.0000] <jgraham>
Right so there is some useful stuff you can test

[15:48:26.0000] <jgraham>
But without any way to read back the console it's unclear that an implementation like console = {log: function(data){}} wouldn't pass most tests

[15:53:45.0000] <Domenic>
good enough for web compat

[16:12:39.0000] <TabAtkins>
Yeah, just need a bunch of manual tests unfortunatekly.