2017-12-01
[16:20:43.0000] <Domenic>
annevk: are you able to own reviewing https://github.com/whatwg/html/pull/3260 ? (inputmode)

[16:57:15.0000] <Domenic>
annevk: also ping on https://github.com/whatwg/html/pull/3221#issuecomment-347262185 (img decoding="")

[20:21:33.0000] <annevk>
Domenic: I was planning on reviewing inputmode once the high-level questions are addressed

[20:22:57.0000] <Domenic>
Yeah, OK, seems like it's on dtapuska's plate for now, just wanted to know if you'd review once he gets back to it or if I should feel responsible :)

[20:24:55.0000] <annevk>
Domenic: I guess the decoding thread concluded in a follow-up issue for possibly a third new feature, but not in changes to the decoding attribute; that should probably be stated though and then an issue raised. Then on Monday or Tuesday we can merge imo

[20:25:32.0000] <annevk>
Domenic: I’m happy to take on inputmode

[20:26:15.0000] <Domenic>
Yay. I'm excited about inputmode (and autocapitalize/autocorrect); they're long overdue updates to make the spec match reality

[20:41:55.0000] <annevk>
Domenic: that MIME type parser patch looks cool (will get to GitHub a couple hours from now)

[20:42:28.0000] <annevk>
Domenic: interesting that you went with a tearoff for parameters

[20:43:08.0000] <Domenic>
Yeah, it seemed a bit nicer, like searchParams

[02:28:43.0000] <Mek>
annevk: the current file-api spec has a ton of informative background/discussion around how they ended up with this particular format for blob URLs. While interesting background (maybe), it doesn't seem to add much. I'm tempted to just rip most of that out, does that sound sensible?

[02:29:23.0000] <Mek>
Also of course all the informative text around resolving/parsing/fetching that is now superseded by the fetch and url specs seems to do more harm then good

[02:29:30.0000] <annevk>
Mek: yeah

[02:30:18.0000] <annevk>
Mek: do it as a PR though so folks have a notice of a day or so

[02:31:08.0000] <Mek>
yeah, definitely don't want to do any major changes without some amount of review

[02:32:37.0000] <annevk>
Mek: FWIW, most WHATWG stuff basically protects the master branch and requires (reviewed) PRs

[02:33:01.0000] <annevk>
tooling is such a wonderful thing

[03:45:43.0000] <KiChjang>
quesiton about valid date/month strings

[03:45:44.0000] <KiChjang>
https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-string

[03:46:12.0000] <KiChjang>
so a date string is considered valid if it consists of the components outlined by that part of the spec

[03:46:29.0000] <KiChjang>
is it valid ONLY if it contains those components?

[03:46:50.0000] <KiChjang>
in other words, would "2014-01-01-1" be valid date string?

[03:53:49.0000] <annevk>
KiChjang: how could that be valid?

[03:54:12.0000] <nox>
annevk: KiChjang wants the spec to say "consists ONLY of the components …".

[03:55:15.0000] <annevk>
I think that would require rewording a lot of factual statements which I'm not sure would be beneficial

[03:55:55.0000] <KiChjang>
annevk, yeah, because i'm reading it as "as long as a string consists of these components, then it's a valid date string"

[03:56:01.0000] <annevk>
"A URL's port is a 16-bit unsigned integer" vs "A URL's port is ONLY a 16-bit unsigned integer"

[03:56:02.0000] <nox>
I've never seen uses of 'consist of' to refer only to a subset of the parts.

[03:56:20.0000] <nox>
If it refers to a subset, you usually read "mainly consist of" or something similar.

[03:58:01.0000] <annevk>
I could see rephrasing these though

[03:58:10.0000] <nox>
'Attributes are placed inside the start tag, and consist of a name and a value, separated by an "=" character.'

[03:58:16.0000] <annevk>
Just make it "A valid month string is X followed by Y followed by Z"

[03:58:30.0000] <annevk>
There's no need for these variables in the definition and such

[03:58:37.0000] <KiChjang>
annevk, i'm thinking of it in terms of exhaustiveness

[03:58:51.0000] <KiChjang>
because it seems to me that it allows for additiona characters at the end

[03:59:19.0000] <nox>
KiChjang: Why?

[03:59:42.0000] <nox>
Does the thing I pasted let you think that 'a="b"c' is an attribute too?

[03:59:59.0000] <annevk>
KiChjang: I don't think that's true with the current language (though I'll note again I'd support simplifying it)

[04:01:24.0000] <KiChjang>
nox: yes, because a is the name, and "b"c is the value

[04:02:04.0000] <nox>
Not sure I understand what you mean.

[04:03:21.0000] <nox>
Looking at https://www.google.fr/search?q=inurl:https://html.spec.whatwg.org/multipage/+%22consist+of%22 I feel like you don't interpret 'consist of' correctly.

[05:47:24.0000] <annevk>
Domenic: that code coverage thing is so great

[06:05:37.0000] <Domenic>
^_^

[06:19:52.0000] <annevk>
Domenic: ideas on how to deal with the code points? Some contexts cannot deal with non-latin1. Should we ignore those tests in the respective harness or encode that in the test somehow?

[06:20:25.0000] <Domenic>
Seems important to test... what contexts, and what does "not deal with" mean?

[06:20:57.0000] <Domenic>
The parser will fail for such code points anyway, right?

[06:21:28.0000] <annevk>
Domenic: consider the Content-Type header

[06:21:39.0000] <annevk>
Domenic: it takes 0x00 to 0xFF

[06:21:58.0000] <annevk>
Domenic: so if you pass it U+0100 you cannot really express that

[06:22:06.0000] <annevk>
Domenic: you could UTF-8 encode it, but then you're testing something else

[06:22:35.0000] <annevk>
Domenic: the parser will ignore the parameters or fail if part of type/subtype

[06:24:13.0000] <Domenic>
So why not test it just like any other invalid code point though

[06:24:23.0000] <Domenic>
Oh I see

[06:24:28.0000] <annevk>
Domenic: strings <> bytes

[06:24:29.0000] <Domenic>
This is in bytes-only contexts

[06:24:33.0000] <annevk>
hai

[06:24:55.0000] <Domenic>
Lemme look at the test code, since I don't think we tested any APIs that use ArrayBuffers...

[06:25:01.0000] <annevk>
Note that Request/Response are such a context too

[06:25:14.0000] <annevk>
Due to ByteString

[06:25:52.0000] <Domenic>
I see, this is mainly about what happens on the Python side hmm

[06:25:57.0000] <annevk>
Blob/File are not though and I'm not convinced MIMEType should use ByteString

[06:26:17.0000] <Domenic>
Why not?

[06:26:31.0000] <Domenic>
I guess Blob/File are not for compat reasons

[06:26:37.0000] <Domenic>
But new APIs should, I'd think

[06:26:42.0000] <annevk>
Domenic: MIMEType would end up with lots of double conversion

[06:27:02.0000] <Domenic>
Only on a spec level

[06:27:12.0000] <annevk>
Domenic: unless someone redefines the parser to operate on byte sequences, but then it gets weird for non byte input

[06:27:25.0000] <Domenic>
Don't you have a byte parser?

[06:27:29.0000] <Domenic>
It just isomorphic encodes

[06:27:54.0000] <annevk>
Domenic: I guess we can do it and hope impl are better (and hope Infra at some point abstracts)

[06:28:04.0000] <Domenic>
I guess MIMEType would throw anyway if you gave it invalid code points

[06:28:13.0000] <annevk>
Domenic: yeah, I think it should

[06:28:20.0000] <Domenic>
So it doesn't need to use ByteString, since that just moves most of the checks, but not all, to the IDL layer

[06:28:25.0000] <annevk>
Domenic: and since I get to do it most likely it would just throw TypeError

[06:28:50.0000] <Domenic>
Anyway back to the question

[06:29:16.0000] <annevk>
So can't use navigable as a distinguisher due to Request/Response

[06:29:26.0000] <annevk>
The best thing I can come up with is that the harness needs to filter

[06:29:47.0000] <Domenic>
Hmm yeah I guess that's better than adding it to the data file

[06:30:03.0000] <annevk>
For Request/Response we'd also want to add a filter that it throws for 0x00 and 0x0C/0x0A

[06:30:33.0000] <annevk>
Same for Content-Type, but there's some additional bytes that won't work due to WPT limitations

[06:30:47.0000] <Domenic>
Seems reasonable

[06:31:06.0000] <annevk>
Okay, so I'll go with that and attempt at some documentation in the README

[06:32:45.0000] <Domenic>
I still feel like we should be testing what happens when you send invalid/weird Content-Type headers to servers... but I guess that's really just a test of your server-side framework and whether it does any canonicalization...

[06:41:16.0000] <annevk>
Domenic: there are such tests

[06:41:41.0000] <annevk>
Domenic: did you look at the other PRs? https://github.com/w3c/web-platform-tests/pull/8422

[06:42:24.0000] <annevk>
Domenic: that sends e.g. "charset=ascii" to the server and verifies that the browser doesn't change it

[06:42:49.0000] <Domenic>
Yeah, I guess that's testing that wptserve doesn't do any canonicalization

[06:52:35.0000] <ecobos>
https://drafts.csswg.org/ seems down for me?

[07:05:01.0000] <ecobos>
works now, shrug

[08:15:58.0000] <annevk>
Domenic: looks like generated tests are not getting done today

[08:16:19.0000] <annevk>
Domenic: but I've some Python locally that is going in the right direction

[08:16:40.0000] <annevk>
Domenic: exhaustive means a thousand tests or so though; not sure if we want browsers to run all of those all the time...

[08:22:27.0000] <annevk>
Also, the next format I come up with will have !/! or +/- or some such as MIME type

[08:22:44.0000] <annevk>
Does Bitcoin have some kind of format? $/$ is valid...

[08:25:30.0000] <wanderview>
"Change quote style in lipfuzz example"

[08:25:36.0000] <wanderview>
/me wonders what "lipfuzz" is...

[09:27:58.0000] <Domenic>
wanderview: see if you get it after reading the example: https://streams.spec.whatwg.org/#example-ts-lipfuzz

[09:37:02.0000] <annevk>
Domenic: script I have locally generates 885 tests

[09:37:31.0000] <annevk>
Domenic: gonna try integrate it later and see what blows up, but have to do some other things for a bit

[09:46:29.0000] <hober>
how does one rename a user account on the wiki?

[09:48:51.0000] <annevk>
GPHemsley: Krinkle: any idea how to rename accounts on MediaWiki?

[09:49:08.0000] <annevk>
See question by hober above

[09:59:10.0000] <hober>
i think maybe it requires this extension: https://www.mediawiki.org/wiki/Extension:Renameuser

[10:02:04.0000] <annevk>
hober: ah, it might be best to email GPHemsley directly then

[10:02:27.0000] <annevk>
Not entirely sure when he's online

[10:02:33.0000] <hober>
k

[10:02:35.0000] <hober>
thanks

[10:34:11.0000] <Krinkle>
annevk: Yep, Renameuser it is. It's bundled by default in most distros, so might already be there.

[10:34:28.0000] <Krinkle>
or not :) - https://wiki.whatwg.org/wiki/Special:Version

[10:34:52.0000] <annevk>
Yeah, alas

[10:49:06.0000] <wanderview>
JakeA: worker script loads don't get a manual redirect mode, right?  we only do that for windows to support their weird redirect logic?

[10:50:35.0000] <JakeA>
wanderview: I thought redirects weren't allowed. Anyway, in India, will catch up with messages next week.

[10:51:18.0000] <wanderview>
JakeA: ah, ok... I believe same-origin redirects are legal for worker scripts... good night

[10:51:43.0000] <wanderview>
service worker scripts are not allowed to redirect, but dedicated workers can

[11:01:52.0000] <annevk>
Yup, shared same as dedicated

[11:21:49.0000] <tobie>
TabAtkins: is https://api.csswg.org/bikeshed/ having issues?

[11:22:29.0000] <TabAtkins>
Dunno, don't use it. It seems to load correctly, at least. What problem are you having?

[11:22:43.0000] <tobie>
I'm getting a 400 for this: https://api.csswg.org/bikeshed/?url=https%3A%2F%2Fraw.githubusercontent.com%2Ftobie%2Fwebidl%2F79a0f335ea4420a9092a27fdd10f349f35e64a3e%2Findex.bs&md-warning=not%20ready

[11:23:07.0000] <TabAtkins>
I'll ping plinss, he's the maintainer of that server.

[11:23:12.0000] <tobie>
TabAtkins: I probably did something silly

[11:23:20.0000] <tobie>
TabAtkins: cool thanks

[11:24:06.0000] <wanderview>
html.spec.whatwg.org is down?

[11:27:55.0000] <wanderview>
annevk: you seeing that? ^^^

[11:28:18.0000] <wanderview>
stuck on TLS handshake...

[11:32:34.0000] <annevk>
wanderview: hmm, foolip, MikeSmith ^^

[11:33:46.0000] <TabAtkins>
tobie: plinss reports it's an issue on his side, he'll work on it

[11:33:57.0000] <tobie>
TabAtkins: oh, cool :) ty

[11:45:45.0000] <wanderview>
JakeA: for your reading next week: https://github.com/w3c/ServiceWorker/issues/1239

[12:38:53.0000] <TabAtkins>
tobie: Ahahahaha, I read your comment in #css and thought it was from plinss. The error was def on your side, sorry. ^_^

[12:39:10.0000] <tobie>
TabAtkins: I thought so

[12:39:34.0000] <tobie>
TabAtkins: seems it's an update to bikeshed that's causing an error to something that was working fine before

[12:40:00.0000] <TabAtkins>
I'll check it out, I've been working on indents lately (fixing some bugs).

[12:40:46.0000] <tobie>
TabAtkins: looks like it's related

[12:41:08.0000] <TabAtkins>
Yeah, I checked the error message. ^_^

[13:05:03.0000] <Domenic>
wanderview: works for me, plus http://downforeveryoneorjustme.com/html.spec.whatwg.org , but we are switching some hosting around, so it could be DNS fun times...

[13:06:04.0000] <wanderview>
Domenic: wfm now


2017-12-02
[07:42:06.0000] <zcorpan>
Hello whatwg

[12:33:53.0000] <GPHemsley>
annevk, hober, Krinkle: We run MW via git, so everything has to be installed explicitly

[12:34:08.0000] <GPHemsley>
/me waves at zcorpan 

[13:03:04.0000] <annevk>
GPHemsley: are you willing to do it?

[13:03:23.0000] <GPHemsley>
I wanna upgrade first, but yeah

[13:03:35.0000] <GPHemsley>
looking into it now

[13:03:51.0000] <annevk>
Thanks!


2017-12-03
[17:01:09.0000] <GPHemsley>
foolip: Something is definitely killing jobs based on memory usage or somesuch

[17:03:45.0000] <GPHemsley>
foolip: there also appear to be 10 instances of apache running right now o_0

[17:08:44.0000] <GPHemsley>
foolip: We have no swap space

[17:08:52.0000] <GPHemsley>
https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors

[17:09:16.0000] <GPHemsley>
https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

[17:27:14.0000] <GPHemsley>
TabAtkins: Does background-image support protocol-relative URLs?

[17:27:30.0000] <GPHemsley>
or, I guess, the url() function

[17:44:50.0000] <GPHemsley>
annevk: I want to put off installing any new extensions until we can get swap space set up and I can confirm the upgrade was completed successfully

[17:45:00.0000] <GPHemsley>
annevk: Perhaps file an issue against misc-server?

[17:45:04.0000] <GPHemsley>
actually, I probably should too

[17:49:16.0000] <GPHemsley>
foolip: Filed https://github.com/whatwg/misc-server/issues/45 for you

[20:57:10.0000] <TabAtkins>
GPHemsley: It should, yeah

[01:38:02.0000] <tobie>
annevk: btw: https://github.com/whatwg/html/pull/3260#issue-277154865

[01:44:18.0000] <annevk>
tobie: cool, should I merge .pr-preview?

[01:46:30.0000] <tobie>
annevk: you can

[01:47:49.0000] <annevk>
tobie: I might have some quibbles on whatpr.org URLs

[01:48:04.0000] <annevk>
tobie: it seems for the diff URLs the initial whatwg/ folder is not needed

[01:48:19.0000] <annevk>
tobie: and for the non-diff URLs the initial username/ folder is not needed

[01:48:46.0000] <tobie>
annevk:  yeah, I agree, but that would really complicate things on the pr-preview side.

[01:50:32.0000] <tobie>
annevk: I might look into it at some point, but that's really a v2 feature

[01:55:06.0000] <tobie>
annevk: it would be nice to see if there are commands I can send via the wattsi server to add a warning to the output, and maybe get rid of the navigation which is confusing

[01:56:25.0000] <tobie>
annevk: the other option is to do that via post-processing on the pr-preview side, but I'm concerned about the load increase this will generate (and related hosting costs)

[02:02:33.0000] <annevk>
tobie: seems hard to fix in v2 unless you’d add redirects I guess

[02:03:22.0000] <annevk>
tobie: not sure how wattsi server works, file an issue against wattsi?

[02:04:24.0000] <tobie>
annevk: seems hard to fix in v2 unless you’d add redirects I guess <-- no, those past links would stay as is. Only new ones would get fixed

[02:07:26.0000] <annevk>
Hmm

[02:09:49.0000] <tobie>
annevk: https://github.com/whatwg/wattsi/issues/64

[02:12:24.0000] <tobie>
annevk: https://github.com/whatwg/wattsi/issues/65

[02:13:47.0000] <tobie>
annevk: note that the benefits of the current link system, is that those match what github uses really closely

[02:14:38.0000] <tobie>
annevk: I'm wary of solutions that trade consistency for minor esthetic reasons, tbh. You end up regretting those at some point.

[02:55:05.0000] <annevk>
I’m not seeing the consistency, prolly best to chat during a work day

[04:47:30.0000] <tobie>
annevk: consistency with gh URLs and the rest of pr-preview.

[04:47:44.0000] <tobie>
But agreed. Let's chat Monday.


2017-12-04
[21:17:50.0000] <gg20>
Hello?

[21:20:02.0000] <gg20>
sounds pretty quiet in here

[21:59:55.0000] <annevk>
That may be because it’s IRC and not Skype

[23:42:28.0000] <tkore\work>
lol @annevk

[00:44:48.0000] <tobie>
annevk: thought the urls through and you were right, I can dramatically simplify them.

[00:45:14.0000] <annevk>
\o/

[00:55:00.0000] <tobie>
annevk: settled for:

[00:55:12.0000] <tobie>
https://www.irccloud.com/pastebin/oNS0tw98/

[00:56:12.0000] <tobie>
annevk: it's important to do: /infra/45/7dfd134.html instead of /infra/7dfd134.html, otherwise you get lots of noise in diffs (e.g. between PR numbers)

[00:56:43.0000] <tobie>
When you have multiple PRs that have the same merge base

[00:56:58.0000] <annevk>
tobie: it seems nice to include the PR number actually

[00:57:20.0000] <annevk>
tobie: gives you some assurance you're looking at the correct thing

[00:57:24.0000] <tobie>
annevk: we could even do it for the diffs

[00:57:50.0000] <annevk>
tobie: please; thanks for doing this

[01:46:31.0000] <tobie>
annevk: done.

[02:50:26.0000] <annevk>
Domenic: I'm surprised https://lcov-report-sngrqbipez.now.sh/serializer.js.html ends up with 100% coverage even though nothing calls it with excludeParameters; I guess it doesn't do "dead code" detection, but that would be nice

[04:09:52.0000] <annevk>
hsivonen: isn't this removal of non-UTF-8 file paths still a theoretical concern even on modern platforms?

[04:10:01.0000] <annevk>
hsivonen: I thought APFS didn't enforce UTF-8 for instance

[05:45:02.0000] <hsivonen>
annevk: on Unix (except HFS+), file paths are sequences of bytes

[05:45:14.0000] <hsivonen>
annevk: on Windows, they are sequences of 16-bit units

[05:45:50.0000] <hsivonen>
annevk: so pretty much everywhere (except HFS+), paths are not guaranteed to be representable as Unicode

[05:46:30.0000] <hsivonen>
annevk: however, on *nix these days, if you want to make a text string out of a file path, decoding as UTF-8 is what makes sense

[05:46:40.0000] <hsivonen>
annevk: and on Windows, interpreting as UTF-16

[05:47:00.0000] <hsivonen>
annevk: so any tool that assumes that paths fit in text is lossy

[05:47:48.0000] <hsivonen>
annevk: so if you are writing a backup tool or another kind of tool that has to be able to deal with all files, it's fundamentally wrong to let paths be represented as text as an intermediate operation

[05:47:48.0000] <annevk>
hsivonen: why not write non-lossy tooling? Or are we only talking about displaying these?

[05:48:28.0000] <hsivonen>
annevk: however, for many apps, it's good enough to be lossy and it's too hard to enforce the discipline that paths must be non-text objects

[05:48:52.0000] <annevk>
If we ever get RustFS I hope it guarantees Unicode

[05:49:21.0000] <hsivonen>
annevk: I argue that a Web browser, especially one whose parts are implemented in JS, is a program that just has to be lossy for paths that aren't valid UTF-16 on Windows or valid UTF-8 on *nix

[05:50:00.0000] <hsivonen>
annevk: I might have a different opinion if no part of file handling was implemented in JS

[05:50:07.0000] <hsivonen>
annevk: i.e. if it was all Rust

[05:50:29.0000] <hsivonen>
annevk: Rust's standard library models this stuff the right way

[05:50:31.0000] <hsivonen>
few things do

[05:51:17.0000] <hsivonen>
(Rust gets it right when few things do is a general theme when it comes to Unicode-ish things)

[05:52:53.0000] <hsivonen>
annevk: one thing on my mental todo list is researching if Microsoft browsers can represent arbitrary Unicode in file: URLs these days

[05:53:37.0000] <hsivonen>
it would be nice if we could make file: URLs on Windows less lossy than they are now in Firefox

[05:55:27.0000] <hsivonen>
paths are one of those things that superficially look like text, so programmers think it's OK to process them as text, but there's a subtle mismatch

[05:55:56.0000] <hsivonen>
this arises from kernel devs (both NT and *nix) kernel devs making it not their problem, so it's every userland app's problem

[05:56:33.0000] <hsivonen>
but with HFS+, we see what happened when well-intentioned kernel devs tried to make it their problem

[05:56:37.0000] <hsivonen>
from the frying pan into the fire

[05:59:18.0000] <annevk>
hsivonen: you mean the not quite NFD normalization?

[05:59:34.0000] <hsivonen>
annevk: yes

[06:00:14.0000] <annevk>
hsivonen: Rust is a good pointer point that low-level folks can get it correct

[06:01:32.0000] <annevk>
hsivonen: I'm a little sad APFS didn't enforce UTF-8, although even then I guess you haven't quite solved the display problem, but at least you use strings

[06:40:37.0000] <gsnedders>
annevk: I presume also wanting everything to be convertable from HFS+ to APFS made it impossible to enforce

[06:41:25.0000] <gsnedders>
(using text for all files is one thing Python 3 got wrong, IMO, as it makes it impossible to open some files)

[06:44:29.0000] <annevk>
gsnedders: why, HFS+ was Unicode-compatible

[06:44:51.0000] <annevk>
Oh Python. Whenever I use Python I always struggle with Unicode

[06:45:14.0000] <annevk>
You'd think that converting between integers and characters would be easier

[06:48:18.0000] <gsnedders>
annevk: mismatched surrogates, no?

[06:50:30.0000] <annevk>
gsnedders: I thought not

[07:06:27.0000] <Domenic>
annevk: that branch gets taken a bunch of times though since the zero-parameters case occurs. If we'd written it as two if statements we would have seen loss of coverage, yeah.

[07:07:26.0000] <annevk>
Domenic: seems the tooling should see that somehow

[07:07:57.0000] <annevk>
Domenic: and flag part of the || conditional as always being false

[07:08:51.0000] <Domenic>
Yeah, right now it only does branch granularity, not expression granularity; I haven't seen tooling for expression granularity yet.

[07:24:42.0000] <hsivonen>
annevk: looks like Python 3.6 tried to add back support for non-Unicode file paths on *nix. Not sure if paths that are invalid UTF-16 are representable in Python 3.x on Windows

[07:24:49.0000] <hsivonen>
annevk: https://www.python.org/dev/peps/pep-0519/

[07:35:08.0000] <gsnedders>
hsivonen: oh I'd missed that entirely

[08:32:56.0000] <Mek>
okay, uploaded an initial attempt at better defining blob URLs... still a lot of work to do though...

[10:08:09.0000] <Domenic>
\o/

[10:45:04.0000] <hsivonen>
GPHemsley: I take it that it's by design that MIME sniffing doesn't sniff files that start with BOM as HTML even if the BOM is followed by a pattern that would otherwise sniff as HTML?

[11:51:59.0000] <zcorpan>
hsivonen: maybe ask if abarth remembers?  Iirc the patterns were based on data he gathered

[13:23:38.0000] <paul_irish>
annevk: i gave you Founder privs on this channel

[13:25:04.0000] <paul_irish>
annevk: you can have chanserv op you with: /cs op #whatwg annevk

[13:25:46.0000] <paul_irish>
annevk: and feel free to augment the access list with whoever you want.

[13:30:58.0000] <paul_irish>
I also gave channel op to Domenic, zcorpan, and MikeSmith to round things out a bit.

[13:31:21.0000] <Domenic>
ooh fun

[13:31:25.0000] <Domenic>
thanks paul_irish!

[13:32:18.0000] <paul_irish>
( I don't entirely remember, but I guess this channel was unregistered 7yrs ago, so I kicked that off?  ¯\_(ツ)_/¯ )

[13:39:35.0000] <zcorpan>
Thank you paul_irish

[15:50:05.0000] <TabAtkins>
Yo, anyone reported yet that whatwg.org's https is broken?

[15:51:30.0000] <TabAtkins>
It's specifically html.spec.whatwg.org, actually. The more general domains work.

[15:56:47.0000] <hiroshige>
I also found the issue, but not sure where to report > SSL html.spec.whatwg.org

[15:57:09.0000] <hiroshige>
creating a github issue? (not sure)


2017-12-05
[16:02:16.0000] <hiroshige>
Filed: https://github.com/whatwg/meta/issues/54

[17:54:26.0000] <abarth>
hsivonen, zcorpan : yes

[17:54:39.0000] <abarth>
one of the goals was minimalism

[17:54:53.0000] <abarth>
which means have as narrow a pattern as required for web compat

[17:55:05.0000] <abarth>
BOM + pattern isn't required for web compat

[17:55:09.0000] <abarth>
so isn't in the algorithm

[18:02:47.0000] <MikeSmith>
hiroshige: thanks for reporting that ー will look into it (but it may need foolip to fix, once he gets on for the day)

[18:03:04.0000] <MikeSmith>
and thanks TabAtkins too 🐍

[18:03:39.0000] <MikeSmith>
and thanks paul_irish for ops ☘️

[18:04:26.0000] <MikeSmith>
and oh hello abarth

[18:05:10.0000] <MikeSmith>
TabAtkins: can you please check what IP address html.spec.whatwg.org is resolving to for you?

[18:07:27.0000] <MikeSmith>
it should be 165.227.248.76

[18:08:00.0000] <MikeSmith>
if it’s instead 75.119.197.251 then that’s the problem

[18:08:22.0000] <MikeSmith>
we moved the DNS for it recently

[18:09:38.0000] <MikeSmith>
so you must be hitting a problem with cached DNS somewhere not getting invalidated

[18:10:21.0000] <MikeSmith>
(assuming you don’t have it hardcoded to resolve to 75.119.197.251 in /etc/hosts or whatever)

[18:27:17.0000] <MikeSmith>
but the workaround for now is to hardcode it in an /etc/hosts or equivalent

[18:27:46.0000] <MikeSmith>
add this line:

[18:28:19.0000] <MikeSmith>
165.227.248.76 html.spec.whatwg.org

[18:28:51.0000] <TabAtkins>
It's working for me here at home, but it was failing for me and fantasai at work, so yeah, probably a DNS cache problem.

[18:28:57.0000] <MikeSmith>
yeah

[18:29:10.0000] <MikeSmith>
Hixie says he only make the DNS change about 3 hours ago

[18:29:12.0000] <TabAtkins>
And yeah, ping shows the good IP address here.

[18:29:15.0000] <MikeSmith>
k

[18:29:22.0000] <TabAtkins>
Ah, that would correspond pretty well to when I saw it.

[20:27:54.0000] <abarth>
hi MikeSmith

[21:09:32.0000] <annevk>
Thanks paul_irish, and yeah, I think you did 😊

[01:30:01.0000] <TheWild>
hello

[01:30:31.0000] <TheWild>
what was the reason of removal of support for UTF-16 in TextEncoder?

[01:33:44.0000] <annevk>
TheWild: it was the only place in the web platform that exposed encoding UTF-16

[01:33:57.0000] <annevk>
TheWild: and we're not a big fan of UTF-16, so

[01:34:54.0000] <TheWild>
so no support for UTF-16? What about those language where UTF-16 representation is more compact than UTF-8?

[01:35:45.0000] <TheWild>
languages

[01:36:31.0000] <annevk>
TheWild: given that there's usually markup involved in transporting such language, even ignoring compression, that argument is flawed

[01:37:04.0000] <annevk>
TheWild: see also https://annevankesteren.nl/2009/09/utf-8-reasons and in particular https://lists.w3.org/Archives/Public/www-style/2009Feb/0087.html

[01:37:13.0000] <annevk>
such a language*

[01:37:18.0000] <annevk>
TheWild: hope that helps

[01:37:35.0000] <annevk>
TheWild: oh, https://github.com/whatwg/encoding/issues/18 also has some relevant discussion and workarounds

[01:38:22.0000] <TheWild>
ok, let it be. I'll read later. Thanks annewk.

[01:45:59.0000] <TheWild>
thought my problem was to convert ArrayBuffer to string (so it can be used as a dictionary key) and back, without involving much conversion. Yeah, I can "cast" the ArrayBuffer to Uint16Array and use s += String.fromCharCode(x), but I thought there's faster, more "internal" way.

[01:47:13.0000] <annevk>
TheWild: use a Map?

[01:48:12.0000] <annevk>
TheWild: although I guess that depends what the dictionary is for

[01:48:55.0000] <annevk>
TheWild: but also, unless the ArrayBuffer contains valid UTF-16 you'd get data loss with such a conversion

[01:48:57.0000] <TheWild>
a = new Uint8Array([2, 3]); b = new uint8Array([2, 3]);       in Map, a and b would be treated as different keys.

[01:49:10.0000] <annevk>
TheWild: ah yeah, doh

[01:49:51.0000] <annevk>
TheWild: I think what you want is something that isn't addressed by UTF-16 encoding, as you'd want to preserve lone surrogates

[01:50:22.0000] <annevk>
TheWild: you need an Uint16Array -> String thing which indeed seems like something that could be really fast

[01:50:59.0000] <TheWild>
since ArrayBuffer would hold just some binary data, correct UTF-16 codepoints aren't guaranted. (AFAIR 0xD800 - 0xDBFF and 0xDC00 - 0xDFFF were surrogates)

[01:51:36.0000] <annevk>
TheWild: indeed, encoding them would turn those into U+FFFD so you'd get data loss

[02:19:12.0000] <hsivonen>
abarth: OK. What's your opinion on using different patterns for file: URLs? that is, do you think it would be a) appropriate and b) worthwhile to sniff HTML with UTF-8 BOM but not .html in the file name as text/html when accessed using file: URL?

[02:19:43.0000] <hsivonen>
abarth: are there security considerations relevant to file: for not following the same sniffing as for network resources?

[02:24:02.0000] <JakeA>
annevk: If I have an options dict, can I access its properties "in parallel" or do I need to create variables for all the properties before going parallel?

[02:26:01.0000] <annevk>
JakeA: I would argue that you can, unless you end up manipulating objects on the main thread that way

[02:26:12.0000] <annevk>
JakeA: e.g., if they hold pointers

[02:27:04.0000] <TimothyGu>
TheWild/annevk: at least in case of V8 there are C++ APIs provided for working with 16-bit data as strings conveniently

[02:27:51.0000] <TimothyGu>
e.g. v8::String::NewFromTwoByte() which literally just wraps around the array (after copying)

[02:28:00.0000] <annevk>
TimothyGu: do you know if this came up in TC39 before?

[02:28:11.0000] <annevk>
TimothyGu: seems such an obvious thing to offer

[02:28:20.0000] <TimothyGu>
not sure

[02:28:30.0000] <JakeA>
annevk: cheers!

[02:28:36.0000] <annevk>
I guess I'll ask over in #tc39

[02:28:36.0000] <TimothyGu>
I mean there's String.fromCharCode(..array)

[02:28:53.0000] <annevk>
I see

[02:30:52.0000] <JakeA>
annevk: one more question, is the best practice these days "|options|.{{FooOptions/bar}}" or "|option|'s {{FooOptions/bar}} member"?

[02:31:46.0000] <annevk>
JakeA: I think the latter and maybe |options|["bar"] works too these days if dictionaries are already defined in terms of ordered maps

[02:32:08.0000] <annevk>
JakeA: we discussed this recently somewhere

[02:32:59.0000] <JakeA>
annevk: ta!

[02:33:00.0000] <annevk>
JakeA: per https://github.com/heycam/webidl/issues/453 dictionary["member"] is defined already and the way to go

[02:45:32.0000] <annevk>
hsivonen: given those questions I'm inclined not to reply to https://bugzilla.mozilla.org/show_bug.cgi?id=1422889 for now

[02:47:03.0000] <annevk>
hsivonen: I tend to think it's best to be conservative there too and rely on the OS mapping given the number of subtle exploits with getting the user to run local files in their browser

[02:47:14.0000] <annevk>
hsivonen: it's rather unfortunate we still have to support that I think

[07:09:25.0000] <Domenic>
annevk: TheWild (who isn't here): it seems like this is a specific case of the fact that Maps don't have a good equality protocol besides === (well, actually SameValueZero).

[07:09:37.0000] <Domenic>
That would be the language-level change I would expect

[07:10:19.0000] <Domenic>
Reducing things to immutable values (whether they be strings or bigints) just so that they can serve as good map keys is a "hack" IMO. Although a very necessary one given the language as it is today.

[07:13:06.0000] <annevk>
I guess that's fair, representing strings as bytes and bytes as strings is only ever done as a workaround for something that's lacking

[07:24:15.0000] <Domenic>
MikeSmith: https://github.com/validator/validator/commit/d954e3c20f53a8015c4d2de06316c6b0fef23406 is nice :)

[07:43:08.0000] <a-ja>
is there a channel for css wg? looking to find fantasai on irc, about a possible hanging-punctuation issue

[07:45:06.0000] <a-ja>
if not, can email i guess. no hurry or anything...very edge-case

[07:47:33.0000] <Ms2ger>
#css on irc.w3.org

[07:50:14.0000] <a-ja>
Ms2ger, tks...not on there unfortunately.  that's where i looked first before asking.

[07:51:04.0000] <Ms2ger>
That doesn't mean it's not the channel you're looking for :)

[07:52:00.0000] <a-ja>
true enough.  or looking for the wrong nick.

[07:53:20.0000] <Ms2ger>
fantasai is in there, but you aren't?

[07:55:31.0000] <a-ja>
Ms2ger, doh...looking on freenode.  tks

[08:18:30.0000] <abarth>
hsivonen: sounds like a tricky problem.  I haven't thought about it in enough detail recently to have an informed opinion.  Another thing to consider for file URLs is whether to use the file extension as input.  That's what other programs use on commonly used operating systems (although obviously not for all operating systems).

[08:22:34.0000] <gsnedders>
I presume no browsers support xml:id for things like the id selector?

[08:33:50.0000] <annevk>
gsnedders: they must not

[08:44:06.0000] <gsnedders>
annevk: is that actually specified for Selectors?

[08:45:05.0000] <gsnedders>
/me somewhat suspects this is something that falls through the cracks with how Selectors is meant to be agnostic about what it's matching against

[08:50:08.0000] <annevk>
gsnedders: many things are not specified from that perspective

[08:50:26.0000] <annevk>
gsnedders: as I’ve complained about in the past

[08:53:47.0000] <annevk>
gsnedders: the way DOM deals with this is only giving id= power

[11:41:38.0000] <TabAtkins>
Selectors is indeed agnostic about this, intentionally. The host language defines (or *should* define) what concepts map to what in the Selectors data model.  The DOM mapping is fairly intuitive, but if nothing in HTML specifies how xml:id works, it should.

[11:45:20.0000] <gsnedders>
TabAtkins: HTML just defers to DOM on what's an id

[11:45:40.0000] <gsnedders>
TabAtkins: (it doesn't define how xml:id in the same way it doesn't define how thisisbogus works)

[11:46:11.0000] <gsnedders>
TabAtkins: so DOM should define how the DOM tree maps to the Selectors data model, in your view?

[11:46:32.0000] <TabAtkins>
That's been the stated intention for well over a decade, yes.

[11:50:10.0000] <gsnedders>
/me files an issue and runs away

[11:50:17.0000] <gsnedders>
(https://github.com/whatwg/dom/issues/542)


2017-12-06
[18:07:46.0000] <MikeSmith>
Domenic: I figured you’d like that change

[18:08:17.0000] <MikeSmith>
when you have time, please test and let me know if I missed anything

[18:08:22.0000] <MikeSmith>
I mean for that whole PR

[18:08:35.0000] <MikeSmith>
all the script and style stuff

[18:08:57.0000] <MikeSmith>
https://github.com/validator/validator/issues/560 that is

[18:09:49.0000] <MikeSmith>
TabAtkins: FYI, I added integrated CSS checking of <style> contents to the HTML checker

[18:10:19.0000] <MikeSmith>
using the same backend code from the W3C CSS checker

[01:15:47.0000] <annevk>
TabAtkins: as I've said for about a decade, that data model is broken 😊

[01:16:09.0000] <Ms2ger>
What's the initial value of https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#selection-direction  ?

[01:17:11.0000] <annevk>
Ms2ger: I don't know, but it seems like it should depend on the platform

[01:18:31.0000] <Ms2ger>
If the platform doesn't "support that direction" (as in the next sentence), would it ever be appropriate to return "none" from the getter?

[01:20:54.0000] <annevk>
Ms2ger: if it doesn't support "none" I don't think it should be

[01:21:05.0000] <Ms2ger>
/me files an issue to clarify

[01:21:13.0000] <annevk>
Ms2ger: but I agree that it's a little vague in the same way your initial test was vague

[01:22:28.0000] <annevk>
I really hope we can at some point abstract these "depends on platform" better so it's clear what kind of variability there is (and which variability is tightly coupled)

[02:40:46.0000] <annevk>
tobie: I'm pretty sure https://www.w3.org/Bugs/Public/show_bug.cgi?id=23056 can be closed, but I can't find the corresponding commit

[02:42:22.0000] <tobie>
annevk: thanks, I'll take a look

[03:04:30.0000] <annevk>
tobie: speaking of IDL things, is providing "this" as a reference for spec algorithms to use on the list of priorities?

[03:05:52.0000] <tobie>
annevk: yes

[03:09:40.0000] <annevk>
tobie: also, it seems you didn't reply to https://github.com/heycam/webidl/pull/423#pullrequestreview-77122347

[03:13:41.0000] <tobie>
annevk: I wasn't too sure the first part was a question or a statement. I should have asked.

[03:14:00.0000] <tobie>
annevk: Now I realize it probably was a request to sync. :)

[03:18:26.0000] <tobie>
annevk: wrt to the second part of the question, I assumed there were open issues against wpt and idlharness in https://github.com/heycam/webidl/issues/365, but there are none.

[03:24:58.0000] <annevk>
tobie: yeah, was just trying to get a plan of action

[03:25:03.0000] <annevk>
tobie: I can take more actions

[03:25:24.0000] <annevk>
tobie: might actually do this today and take a break from the MIME type zone

[03:34:41.0000] <annevk>
littledan: what would be a good name for this project so I can give it a label?

[03:35:21.0000] <annevk>
littledan: tobie: I'm gonna go with "needed-for-js" for now

[03:35:32.0000] <littledan>
I think wycatz previously looked into this, calling it "JSIDL". I like that name.

[03:35:48.0000] <littledan>
wycats

[03:35:59.0000] <annevk>
good call

[03:37:20.0000] <annevk>
sprinkled that label around

[03:37:43.0000] <littledan>
annevk, tobie, Domenic: Thanks for all your help here. Thomas Wood from ICL (@IgnoredAmbiance) is also interested in getting involved here, maybe from a standpoint of using this IDL to improve automated analyses/implementation of the JS spec. I'll send him this label; if you have any ideas for what he could work on, that would be helpful

[03:39:33.0000] <annevk>
littledan: it would be good to hear some of the requirements that others might have to make this successful in order to determine priorities

[03:40:13.0000] <annevk>
littledan: adding missing features is probably the least involved at this point; the other things require a good bit more coordination

[03:40:39.0000] <annevk>
littledan: and by others I mean TC39 primarily

[03:52:13.0000] <littledan>
We've already discussed the effort in a few forums that TC39 members can see; to reach more of them, a presentation about the problem at TC39 would probably be helpful

[03:52:50.0000] <littledan>
maybe Domenic is thinking of giving that; otherwise, I'd be happy to arrange for you or tobie to call in to explain the ideas and ask for feedback

[03:58:14.0000] <littledan>
what surprised me in the last couple days is how interested the WebIDL community is to making changes to WebIDL to make this work--this would be an important thing to communicate to TC39

[03:59:20.0000] <annevk>
littledan: I see, I've always supported doing this, but to a large extent it's that we need resources to make it happen

[03:59:41.0000] <annevk>
littledan: in particular the syntax changes require quite a bit of dedicated effort to get right

[04:00:37.0000] <littledan>
which of the syntax changes seem plausible to you?

[04:07:05.0000] <littledan>
maybe we can find help in the TC39 community here, once the problem and areas for work are presented

[04:07:19.0000] <annevk>
littledan: I have some concerns with attributes, but in principle I love all of them

[04:07:32.0000] <annevk>
littledan: I put the attribute concerns in a new issue

[04:14:29.0000] <annevk>
littledan: I also like how your changes are fairly pragmatic

[04:15:00.0000] <annevk>
littledan: e.g., it's not "please do away with all your number types", but "alias double with Number" (and potentially drop double)

[04:19:27.0000] <tobie>
littledan: fwiw, I've been trying to push for convergence between roughly speaking node.js and Web JS for quite some time. In a sense, this is just underlying infra work to make that longer term, higher level goal happen.

[04:25:02.0000] <annevk>
That's already happening, but this would simplify it

[04:35:29.0000] <annevk>
tobie: I think I closed all legacy IDL bugs that could be closed

[04:37:14.0000] <tobie>
annevk: oh, wow! Thanks!

[04:58:41.0000] <Mek>
annevk: would it make sense to add an "exclude query" flag to URL serializing, or should I just copy my URL record, unset the query, and serialize that if that's the behavior I want?

[05:00:42.0000] <annevk>
Mek: unset for now, since it's not widespread I think, but I'd love to know where we want to lose it

[05:02:23.0000] <Mek>
in this case it's for blob URLs where (firefox, but not chrome) ignores query strings when resolving them.

[05:03:22.0000] <Mek>
but yeah, there's a couple of ways I can get that behavior without changing serialization behavior

[05:13:08.0000] <annevk>
Mek: maybe Firefox is wrong?

[05:13:30.0000] <annevk>
Mek: given that you can't get such URLs to begin with, I'm not sure why that shouldn't just be a mismatch in the store

[05:13:45.0000] <Mek>
yeah, looking back at the bugs filed agains blink and webkit for this and the resulting discussion that does seem like the most sensible outcome

[05:14:10.0000] <annevk>
yeah, consumers of exclude query just went back to 0

[05:14:14.0000] <annevk>
yay*

[05:15:31.0000] <Mek>
Arguably the current URL spec agrees with firefox in that it only looks at url's path[0] to look up an entry in the blob URL store (which would mean query strings are ignored), but without actually having a well defiend lookup process that step is pretty ambigious anyway

[05:18:51.0000] <annevk>
Mek: hmm yeah, I guess the question is how the lookup should work and what is stored in the db

[05:48:35.0000] <annevk>
MikeSmith: that validator change broke building HTML I’m pretty sure

[06:49:42.0000] <littledan>
annevk: Thanks, that was my intention. I don't actually see any feature or syntax that I'd want to add which actually contradicts what WebIDL already has; at worst, things would be redundant and overlapping in confusing ways (which is really not great to have long-term)

[07:09:13.0000] <annevk>
littledan: any such cases also seem like something we'd want to work through and either make disappear or call one legacy and continue with the other

[09:25:41.0000] <TimothyGu>
littledan: what's the context on having ECMAScript use Web IDL? Is there a GitHub issue or something I can read through?

[09:27:15.0000] <annevk>
TimothyGu: inconsistent method definitions are appearing

[09:27:27.0000] <TimothyGu>
...like?

[09:27:53.0000] <annevk>
TimothyGu: littledan has examples, might be Intl mostly

[09:28:42.0000] <annevk>
But yeah, overarching issue would be good or maybe a proposal repo

[09:29:31.0000] <TimothyGu>
Also I understand WebAssembly is going to use Bikeshed for its API spec... is there a repo for that yet?

[09:31:57.0000] <littledan>
PR for WebAssembly using WebIDL: https://github.com/WebAssembly/spec/pull/591

[09:32:17.0000] <littledan>
there's no issue tying the WebIDL/ES thing all together; it is very early

[09:33:03.0000] <littledan>
for new ECMAScript specs, we're sticking to specific conventions and I don't think new things deviate from each other, but there's a lot of copypasta and it's difficult to author and review

[09:33:36.0000] <littledan>
lots of new proposals needlessly deviate early in their development by not having a clear model for what to follow

[09:33:57.0000] <littledan>
if we want to add to the JS standard library, I'm worried the current process won't scale

[09:45:30.0000] <TimothyGu>
tobie: it's not ES properties vs IDL attributes that's the difference, but how their names are used. See https://github.com/heycam/webidl/pull/483#issuecomment-349491093

[09:46:05.0000] <TimothyGu>
between whether or not "'s are used

[09:46:25.0000] <tobie>
TimothyGu: yeah, didn't mean to imply a prop vs attr diff, but precisely how their names were used.

[09:47:23.0000] <TimothyGu>
tobie: wait so is <code>entries</code> what you're suggesting

[09:47:31.0000] <TimothyGu>
or rather <code>"entries"</code>

[09:48:27.0000] <TimothyGu>
or just "entries"

[09:48:54.0000] <tobie>
TimothyGu: so my rationale was to say that if you're saying: the x named "foo"

[09:49:35.0000] <tobie>
… you're really just putting quotes around a word, and there's no particular reason do mark it up specially in any other way.

[09:50:45.0000] <tobie>
TimothyGu: we agree that <code class=idl>foo</code> describes the idl thing itself.

[09:51:55.0000] <TimothyGu>
The difference being the name isn't a word. It's an identifier. That leads back to the original problem: I want to be very clear about the spacing in identifiers, and monospace font is the best way to do that

[09:52:32.0000] <TimothyGu>
otherwise we can get "<LF>identifier" because of automatic word wrapping rather than " identifier" as intended

[09:53:03.0000] <tobie>
TimothyGu: but those aren't identifiers, they're JS (infra) strings, no?

[09:54:12.0000] <tobie>
TimothyGu: there's a difference between saying: the x named "foo" and the value of x is (the string) "<code>foo</foo>"

[09:55:20.0000] <TimothyGu>
I'm not sure we are talking about the same thing

[09:55:49.0000] <tobie>
TimothyGu: we're not (that's what what I'm failing to point out)

[09:56:15.0000] <TimothyGu>
/me deep breathe

[09:56:47.0000] <TimothyGu>
so there are a few scenarios. I'm going to list all of them out, and you tell me what you think should be the case

[09:57:15.0000] <TimothyGu>
1. Call the then property of |O|.

[09:57:30.0000] <tobie>
TimothyGu: the spacing issue arose in what is clearly a string (https://heycam.github.io/webidl/#ref-for-dfn-class-string)

[09:57:44.0000] <TimothyGu>
2. If |O| has a property called then

[09:57:55.0000] <TimothyGu>
3. If |str| is "then"

[09:58:40.0000] <TimothyGu>
tobie: yes, but it's concatenating an identifier with a string, which is implicitly saying that identifiers *are* strings

[09:59:37.0000] <tobie>
TimothyGu: well, well, well...

[10:00:02.0000] <TimothyGu>
or is that a stretch

[10:00:33.0000] <tobie>
TimothyGu: Frankly, that's questionable either way

[10:00:54.0000] <tobie>
But let me address your 1-3 examples first

[10:00:55.0000] <annevk>
Domenic: encodeURI is close to USVString, but not close enough

[10:00:58.0000] <TimothyGu>
and to make things worse property names in JS are strings, not identifiers, while they in IDL are identifiers, not strings

[10:01:54.0000] <tobie>
so (3) is clearly: If |str| is "<code>then</code>"

[10:02:50.0000] <tobie>
(1) should be: Call the <code class=idl>then</code> property of |O|. (to follow the ES convention)

[10:03:34.0000] <tobie>
(2) I find weird and I think it the contentious one.

[10:04:35.0000] <tobie>
 If we said something like: If |O| has a property whose identifier is then

[10:05:38.0000] <TimothyGu>
that would only work for a subset, since JS property names can have spaces in them

[10:06:17.0000] <tobie>
I was suggesting these should be quoted: "then"

[10:06:54.0000] <TimothyGu>
Agreed on the quoted. But should there be <code>?

[10:07:03.0000] <tobie>
so: If |O| has a property called "then"

[10:07:21.0000] <tobie>
possibly

[10:07:34.0000] <tobie>
but then not with class=idl

[10:07:59.0000] <TimothyGu>
hmm

[10:08:04.0000] <tobie>
because we're really referring to them as either a string or just a quoted piece of text

[10:08:13.0000] <tobie>
not as an idl thing

[10:08:28.0000] <tobie>
for example, you could write:

[10:08:29.0000] <annevk>
Is there no precedent in ECMAScript to follow?

[10:09:07.0000] <TimothyGu>
annevk: there are, but ES doesn't have the <code class=idl> vs <code> distinction.

[10:09:38.0000] <tobie>
let |k| be the string "<code>foo</foo>"

[10:09:38.0000] <tobie>
call the property |k| of |O|

[10:10:01.0000] <tobie>
you don't really know that k is going to be used as an idl prop until it is

[10:10:19.0000] <TimothyGu>
That makes sense

[10:10:57.0000] <TimothyGu>
So the *definitions* in the spec currently follow the form "a property named “forEach” must exist with attributes"

[10:10:57.0000] <tobie>
So I don't really have an opinion as to whether these should be "<code>txt</code>" or just "txt",

[10:11:02.0000] <annevk>
I see, I guess I didn't know about class=idl

[10:11:07.0000] <tobie>
but I don't like the class=idl part

[10:11:42.0000] <TimothyGu>
would it be better to have "a <code class=idl>forEach</code> property must exist with attributes", or "a property named "<code>forEach</code>" must exist with attributes"

[10:12:16.0000] <annevk>
TimothyGu: I'd go with the former

[10:12:23.0000] <tobie>
I don't really care either way

[10:12:29.0000] <tobie>
wfm

[10:12:39.0000] <TimothyGu>
k

[10:13:41.0000] <tobie>
TimothyGu: thanks a bunch, I'll merge this as soon as you fix it

[10:14:06.0000] <TimothyGu>
I'll come back to this later. there's a wildfire burning 3km from me

[10:16:44.0000] <TimothyGu>
and the power just went out

[10:32:17.0000] <annevk>
TimothyGu: shit, take care

[10:32:31.0000] <TimothyGu>
thanks

[10:52:49.0000] <TimothyGu>
tobie: one last question: what about: an interface named "abc"

[10:53:46.0000] <TimothyGu>
I'll go with "<code>abc</abc>"

[10:56:41.0000] <TimothyGu>
and what about: the identifier "abc"? I'm going with: the identifier "<code class=idl>abc</code>" but you might have different opinions

[11:09:34.0000] <tobie>
ES uses: https://tc39.github.io/ecma262/#sec-identifiers-static-semantics-early-errors

[11:09:39.0000] <tobie>
TimothyGu: ^

[11:11:30.0000] <tobie>
TimothyGu: so <code>"txt"</code>

[11:12:05.0000] <tobie>
We should probably just used: "<code>txt</code>"

[11:12:19.0000] <tobie>
Here again, it's just a string

[11:14:48.0000] <TimothyGu>
ah

[11:47:02.0000] <Domenic>
Oh no, don't catch on fire TimothyGu, that would be bad.

[11:47:46.0000] <TimothyGu>
lol indeed

[11:54:11.0000] <gsnedders>
I don't have any personal experience of catching on fire, but I imagine it wouldn't be greate.

[11:54:14.0000] <gsnedders>
*great


2017-12-07
[16:09:21.0000] <Domenic>
annevk: let me know if you want help with https://github.com/whatwg/html/pull/3276 but it seems more up your alley to me... if I'm just being lazy let me know though :)

[19:53:45.0000] <Domenic>
Does anyone know a Python HTML beautifier that will not put inline tags on their own lines?

[02:08:16.0000] <Ms2ger>
If I have a <link id="style3" rel="alternate stylesheet">, does that necessarily imply that link.sheet is null?

[02:09:48.0000] <annevk>
Ms2ger: because no href?

[02:16:53.0000] <Ms2ger>
No, with implied href going somewhere sensible, sorry

[02:26:31.0000] <annevk>
Ms2ger: I don't think it does, at least Firefox would historically load those and populate a CSSStyleSheet

[02:26:50.0000] <annevk>
(I say historically as I've no idea what happened in the last five years or so)

[02:58:33.0000] <tobie>
So does GitHub actually honor [fixup] when selecting the rebase option of web merge?

[03:01:15.0000] <annevk>
tobie: GitHub would not squash for two separate commits, pretty sure

[03:06:39.0000] <tobie>
Ugh

[03:21:47.0000] <annevk>
tobie: you do know about "squash and merge", right?

[03:22:14.0000] <annevk>
tobie: requires a bit of fiddling with the commit message title/body, but it's great otherwise

[03:22:41.0000] <tobie>
annevk: oh, yeah, absolutely. But I'd like to keep some the commits not marked-up with fixup as separate in TimothyGu 's PR

[03:23:00.0000] <tobie>
annevk: https://github.com/heycam/webidl/pull/483

[03:23:48.0000] <annevk>
tobie: note that you have access to TimothyGu's branch so you can just fix it yourself there

[03:24:13.0000] <tobie>
annevk: yeah, I'm aware.

[03:24:49.0000] <tobie>
annevk: it's just I know fixup! has some magic capabilities

[03:24:59.0000] <tobie>
I'm just not super which

[03:25:02.0000] <tobie>
nor where

[03:26:13.0000] <annevk>
I'm not aware of any really, maybe there's some tooling around git rebase that takes them into account and turns them into -f or so

[03:27:29.0000] <tobie>
think it has to do with auto-squash

[03:53:35.0000] <Ms2ger>
tobie, yeah, rebase --autosquash pays attention to fixup!, not sure if anything else does

[03:54:04.0000] <tobie>
ty

[05:22:49.0000] <annevk>
kochi: at what point shall we draft an agenda?

[05:41:22.0000] <annevk>
TimothyGu: if things are no longer dangerous for you, you might want to have another look at https://github.com/whatwg/fetch/pull/579 (data: URLs); if you're still interested

[05:41:31.0000] <annevk>
SimonSapin: you too might want to have a look

[05:50:04.0000] <SimonSapin>
annevk: is "isomorphic decode" the same as decode with ISO-8859-1 (the IANA one)?

[05:51:18.0000] <annevk>
SimonSapin: IANA handles the full byte range? If so, yes

[05:51:28.0000] <SimonSapin>
ok

[06:04:31.0000] <annevk>
SimonSapin: did WTF-8 end up in Rust proper?

[06:04:40.0000] <annevk>
SimonSapin: your repository on it is somewhat unclear

[06:04:50.0000] <annevk>
SimonSapin: (just curious btw)

[06:05:48.0000] <SimonSapin>
annevk: yes, OsStr and Path contain WTF-8 on Windows (and abritrary bytes on Unix)

[06:19:08.0000] <SimonSapin>
annevk: are cross-references indexed daily, with "parse a MIME type" new today?

[06:31:24.0000] <annevk>
SimonSapin: yes and yes

[06:31:47.0000] <SimonSapin>
cool

[06:31:57.0000] <SimonSapin>
anyway the data: PR looks good

[06:32:18.0000] <annevk>
I think it was previously not exported, that was the problem I suspect

[06:32:19.0000] <SimonSapin>
thanks for pushing on all this

[06:32:40.0000] <annevk>
Because we did have a somewhat broken "parse a MIME type" dfn

[06:33:41.0000] <annevk>
SimonSapin: thanks; see you soon 😊

[06:37:32.0000] <Ms2ger_>
Oh, it's next week, is it

[06:38:40.0000] <annevk>
Ms2ger_: it is; I suspect we'll miss you?

[06:40:54.0000] <annevk>
Whoa, html5lib is 11

[07:06:00.0000] <kochi>
annevk: let me sum up agenda so far tomorrow.

[07:07:41.0000] <kochi>
annevk: I guess MS/Apple are okay around the schedule, but let me check.

[07:08:19.0000] <kochi>
annevk: thanks for arranging the venue.

[07:22:55.0000] <annevk>
kochi: yeah, was wondering why they didn't reply thus far

[07:23:41.0000] <annevk>
kochi: I guess we'll do 3 days? 1 day old stuff. 1 day new stuff. 1 day unconference?

[07:25:49.0000] <wanderview>
annevk: kochi: I might be able to come to the web components f2f for a day or two... if I would not be in the way... I want to get more knowledgeable about it, but I don't want to take up someone else's seat at the table

[07:32:39.0000] <annevk>
wanderview: sgtm

[07:32:53.0000] <annevk>
I suspect the meeting room in Toronto is big enough

[07:37:12.0000] <wanderview>
annevk: it will depend a bit one how my wife is doing... but since its only a few hours drive for me I might be able to attend

[07:44:55.0000] <jugglinmike>
annevk: I want to specify some behavior for all ECMAScript realms with the same origin as a given ECMAScript realm. I know that wording is very loose, but do you get my meaning?

[07:51:13.0000] <jugglinmike>
I suppose I can forget about the ECMAScript realm for now

[07:51:24.0000] <annevk>
jugglinmike: roughly

[07:52:25.0000] <jugglinmike>
What I'd like to do is say, "For every browsing context that is same origin as browsing context X"

[07:52:49.0000] <jugglinmike>
(This is for the Permissions specification--I can give more background if you'd like)

[07:53:48.0000] <jugglinmike>
As a starting point, I think it's valid to reference "all top-level browsing contexts"

[07:53:59.0000] <jugglinmike>
Since "the user agent itself has a strong reference to its   top-level browsing contexts." https://html.spec.whatwg.org/#garbage-collection-and-browsing-contexts

[07:54:18.0000] <Mek>
browsing contexts don't really have origins though

[07:55:15.0000] <annevk>
jugglinmike: you can start with browsing contexts

[07:55:30.0000] <annevk>
jugglinmike: but you need to get to active documents or some such before talking about origins

[07:55:45.0000] <annevk>
jugglinmike: note that at this point you're excluding certain realms, such as those found in workers and worklets

[07:56:03.0000] <jugglinmike>
Oooh. Thank you for pointing that out

[07:56:23.0000] <jugglinmike>
I think you are being very kind to me, trying to solve the question as I phrased it

[07:56:38.0000] <jugglinmike>
but I may be going down the wrong path

[07:57:04.0000] <jugglinmike>
because the specification already works with the realms I'm interested in, but it doesn't go through this trouble

[07:57:51.0000] <jugglinmike>
So the first thing I should ask is: is the current text acceptable? If so, I'll just re-use that. Otherwise, I'll keep at this work at formalization

[07:58:01.0000] <jugglinmike>
Here's what I'm referring to

[07:58:15.0000] <jugglinmike>
> If the user grants permission, return "granted"; otherwise return "denied". The user’s interaction may provide new information           about the user’s intent for this realm and other realms with the same origin.

[07:58:50.0000] <jugglinmike>
https://w3c.github.io/permissions/#requesting-more-permission

[07:59:34.0000] <annevk>
jugglinmike: that's roughly fine

[07:59:44.0000] <annevk>
jugglinmike: there's no such thing as "this realm"

[07:59:57.0000] <annevk>
jugglinmike: and to use "same-origin" you actually need to pass it two origins, not realms

[08:01:32.0000] <annevk>
jugglinmike: origins live on settings objects

[08:01:58.0000] <jugglinmike>
Got it. I'll avoid those parts in my patch

[08:03:00.0000] <annevk>
jugglinmike: so from a realm you'd do realm's [[HostDefined]]'s origin for the origin per https://html.spec.whatwg.org/#realms-settings-objects-global-objects

[08:10:26.0000] <Domenic>
realm's relevant setting object's origin is more conventional

[08:10:59.0000] <Domenic>
but you probably just want unit of related similar-origin browsing contexts

[08:12:08.0000] <Domenic>
Reading the actual text: I don't think users have any intentions about realms at all

[08:22:13.0000] <jugglinmike>
Domenic: that sounds right to me, though I think the specification is just trying to avoid making that assumption

[08:22:46.0000] <jugglinmike>
So a browser could present a checkbox that said "Apply this to all realms" if for some reason they thought anyone would know what that meant

[08:22:58.0000] <jugglinmike>
(when prompting for permission)

[08:31:41.0000] <jugglinmike>
Okay, one more thing

[08:32:03.0000] <jugglinmike>
A environment settings object "specifies algorithms for" a realm execution context

[08:32:54.0000] <jugglinmike>
https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object

[08:32:55.0000] <jugglinmike>
This sounds subtly distinct from saying "has a field for a realm execution context"

[08:34:01.0000] <jugglinmike>
So is it right to say, "the realm of an environment settings object"?

[08:37:02.0000] <jugglinmike>
Answer: yes

[08:37:23.0000] <jugglinmike>
"There is always a 1-to-1-to-1 mapping between JavaScript   realms, global objects, and environment settings objects:"

[08:37:23.0000] <jugglinmike>
https://html.spec.whatwg.org/multipage/webappapis.html#realms-settings-objects-global-objects

[08:43:17.0000] <jugglinmike>
jyasskin: Hey there! Do you have a moment to talk about WebDriver integration with the Permissions spec?

[09:58:12.0000] <annevk>
jugglinmike: ooh you're working on WebDriver <3

[09:58:38.0000] <annevk>
jugglinmike: it'd be so nice to be able to write cross-browser automated tests for stuff like the Notifications API or the Storage Standard

[09:58:38.0000] <jugglinmike>
hehe

[09:59:02.0000] <jugglinmike>
Totally!

[09:59:59.0000] <jugglinmike>
The "extension commands" mechanism hasn't been vetted, so I've been proving it out with the Permissions API

[10:00:29.0000] <jugglinmike>
which is itself pretty nuanced

[11:25:19.0000] <jugglinmike>
jyasskin: I'm working on a new patch for Permissions that supports WebDriver but will stand alone. Do you have a minute to let me know if it sounds like a good idea?

[11:25:50.0000] <jugglinmike>
(Asking again since I've been dealing with a spotty network connection today.)

[11:35:01.0000] <jyasskin>
jugglinmike: Sorry, today's my day off to help raise my kid. I'll be back tomorrow if that works.

[11:35:26.0000] <jugglinmike>
Certainly! Thanks for letting me know, jyasskin

[11:35:39.0000] <jyasskin>
Also sorry for not watching that issue.

[11:36:01.0000] <jugglinmike>
No worries at all; it's been months since you gave me some suggestions, after all

[11:36:26.0000] <jugglinmike>
Are you on the US west coast?

[11:36:41.0000] <jyasskin>
Yep

[11:36:44.0000] <jugglinmike>
got it

[11:37:02.0000] <jugglinmike>
I'll come knocking tomorrow morning then

[11:37:06.0000] <jugglinmike>
Enjoy your day off :_

[11:37:09.0000] <jugglinmike>
:)

[12:30:27.0000] <smaug____>
Hmm, IntersectionObserver ...

[12:30:36.0000] <smaug____>
https://w3c.github.io/IntersectionObserver/#dom-intersectionobserver-intersectionobserver "Set this.root to options.root."

[12:30:44.0000] <smaug____>
/me wonders what that really means

[12:31:03.0000] <smaug____>
and https://w3c.github.io/IntersectionObserver/#dom-intersectionobserver-root is also weird

[12:43:22.0000] <smaug____>
Domenic: "Set this.root to options.root." isn't any magical new spec way to say that some internal slot root would be set to options.root, right?

[12:43:35.0000] <annevk>
Nope

[12:44:10.0000] <annevk>
We do want to have “this”, but no dots afaik

[12:45:52.0000] <smaug____>
/me filed a bug

[13:04:26.0000] <smaug____>
and more IntersectionObserver bugs

[13:04:32.0000] <smaug____>
I wonder if it is actively maintained

[13:04:53.0000] <smaug____>
there are lots of open bugs

[13:11:22.0000] <annevk>
smaug____: it’s observed

[13:11:30.0000] <annevk>
nn


2017-12-08
[17:20:12.0000] <kochi>
annevk: 3day conf schedule sounds reasonable.

[19:32:15.0000] <Domenic>
Hmm. https://github.com/WebAssembly/design/issues/1164

[19:38:49.0000] <MikeSmith>
oh lord

[19:38:53.0000] <MikeSmith>
belly laughs

[19:39:22.0000] <MikeSmith>
OP’s comments start out great and just keep getting better

[19:43:05.0000] <GPHemsley>
why are people engaging in good faith when OP clearly is not?

[19:45:49.0000] <MikeSmith>
I think they're testing to see if it's a bot

[20:06:19.0000] <KiChjang>
"i read and write wasm" really?

[20:10:31.0000] <othermaciej>
I think OP is posting in good faith but is misguided (and kind of opinionated)

[20:39:52.0000] <Domenic>
I think I agree with othermaciej. I mostly feel bad for the 786 inboxes who get one email per post in that thread.

[01:24:44.0000] <annevk>
Oh my, our Code of conduct notice on every repo lacks an Oxford comma

[01:24:52.0000] <annevk>
How did that even happen?

[01:41:47.0000] <nox>
That's because Oxford commas shouldn't exist.

[01:49:34.0000] <annevk>
Lies

[02:41:13.0000] <tobie>
annevk, smaug____ : I think the desired syntax is this.[[prop]]

[02:42:16.0000] <smaug____>
tobie: looks reasonable. (I've given up objecting [[foo]] syntax)

[02:43:07.0000] <smaug____>
tobie: in IntersectionObserver spec the issue is that root is also an attribute in the interface

[02:44:00.0000] <smaug____>
so this.root = some value is odd. this.[[root]], if defined what [[]] means, would be good.

[02:45:37.0000] <tobie>
smaug____: yup. It's at the top of my todo list

[02:46:06.0000] <smaug____>
great

[02:46:08.0000] <tobie>
smaug____: https://github.com/heycam/webidl/issues/258

[02:46:32.0000] <tobie>
arguably, it's been at the top of my todolist for a while :-(

[02:47:02.0000] <smaug____>
tobie: I assume "slot children;" isn't going to happen

[02:48:47.0000] <smaug____>
Since that would pollute the API declaration, make it harder to read.

[04:13:00.0000] <JakeA>
annevk: thinking about request.navigationInfo.history vs request.navigationHistory. Happy to avoid a tear-off object, but navigationHistory doesn't sound like a boolean to me. isReloadNavigation, isHistoryNavigation?

[04:13:37.0000] <JakeA>
This is https://github.com/w3c/ServiceWorker/issues/1167#issuecomment-350238893 btw

[04:48:04.0000] <annevk>
JakeA: hmm, maybe tear-off is okay; I'm actually more interested in the question of getting rid of the technical debt before we expose more potentially incorrect APIs

[04:48:31.0000] <annevk>
JakeA: not a big fan of quicksand API design

[04:52:11.0000] <JakeA>
annevk: which parts are you worried about? It seems straight forward to as we already do different things for reload & back/forward elsewhere

[04:52:42.0000] <annevk>
JakeA: basically navigation and history not being defined in interoperable detail

[04:52:43.0000] <JakeA>
annevk: eg there's already https://w3c.github.io/navigation-timing/#idl-def-navigationtype

[04:52:54.0000] <annevk>
JakeA: see the many many issues against whatwg/html on those subjects

[04:53:36.0000] <annevk>
JakeA: the Performance WG is rather notorious for designing quicksand APIs

[04:53:50.0000] <annevk>
JakeA: and also never paying off the technical debt they leave behind

[04:54:19.0000] <annevk>
(quicksand API is a thing I just made up btw, to give this a name)

[04:56:43.0000] <annevk>
JakeA: I guess if we already expose this to some extent we can at least ensure through tests things are consistent, but I'm not particularly pleased

[04:57:49.0000] <JakeA>
annevk: I'll see what I can do to properly plumb it through navigate

[04:57:59.0000] <annevk>
JakeA: also, given that you reduced the scope of the proposal I'm somewhat more comfortable with it

[04:58:09.0000] <annevk>
JakeA: should have read that comment first

[05:41:55.0000] <annevk>
JakeA: gave your comment a thumbs up, let me know if you need something more 😊

[05:42:59.0000] <JakeA>
annevk: ta, will get some tests together than start looking at the specs. We have internal customers that are mostly interested in reload/history, but I don't want to count out needing to split out 'history' later.

[06:48:41.0000] <kochi>
annevk: just updated #w3c/webcomponents/713

[06:48:57.0000] <kochi>
having tomdale@ is a good news

[06:49:26.0000] <annevk>
yeah is

[06:49:39.0000] <kochi>
if not Yehuda

[09:42:27.0000] <jugglinmike>
Hey jyasskin--are you still up to talk today?

[09:56:52.0000] <jyasskin>
jugglinmike: Agh, I have a meeting in 5 minutes, but I'll be free after 11:30 or so. I'll also read your bug.

[10:03:03.0000] <jugglinmike>
Thanks, jyasskin!

[11:00:29.0000] <jyasskin>
jugglinmike: Ok, I might have to disappear for a bit, but I've re-read https://github.com/w3c/permissions/pull/151 and can talk about it intelligibly.

[11:02:58.0000] <jugglinmike>
Got it, jyasskin

[11:03:06.0000] <jyasskin>
jugglinmike: I think your wording for "Interpret parameters.state as if it were the result of an invocation of permission state for typedDescriptor with the argument target made at this moment." is fine. I tried formalizing this state more in https://github.com/w3c/permissions/pull/96 (and #91 and #95), but folks didn't like it.

[11:03:46.0000] <jyasskin>
jugglinmike: re "WebDriver algorithms execute outside of any particular event loop", that's why you need to post to an event loop before modifying fields of a settings object. We don't want to modify those fields concurrently with algorithms using them.

[11:05:37.0000] <jyasskin>
jugglinmike: about the always-granted APIs like "midi", it's fine with me to let the UA reject the change at the beginning of Set Permission instead of the point where it actually tries to change the permission state.

[11:06:07.0000] <jyasskin>
jugglinmike: Did you have any other questions?

[11:06:47.0000] <jugglinmike>
jyasskin: I think so--in response to the feedback you're giving me now :)

[11:08:37.0000] <jugglinmike>
As far as formalizing state: I started down the road of defining a "permission cache" for each environment settings object. I think this is a primitize form of the patch you shared above, and if so, I would expect it to likewise meet resistance. https://github.com/w3c/permissions/compare/master...bocoup:cache

[11:09:14.0000] <jugglinmike>
I didn't got very far with that patch because I wanted to talk with you first. Does the above sound right to you?

[11:11:05.0000] <jugglinmike>
That patch would need to make "New information about the user's intent" into a formal algorithm, and the input would need to be well-defined (I think: a permission descriptor and an environment settings object)

[11:14:59.0000] <jyasskin>
Yeah, I tried hard to define that cache, and could never get agreement about it. That was complicated by some Mozilla folks being mad that permissions.request() was in the spec, and since it's gone, you might have better luck now, but it's not something I'm enthusiastic to try again

[11:15:24.0000] <jugglinmike>
Hmm, okay

[11:16:00.0000] <jugglinmike>
It's too bad your patch didn't go through, but I'm glad to hear that you were thinking along the same lines

[11:16:05.0000] <jyasskin>
I think you're right that the inputs are a permission descriptor and an environment settings object.

[11:16:57.0000] <jugglinmike>
I'll have to take some time to read the review you received for that patch

[11:17:03.0000] <jyasskin>
If you do want to try again, I think #91, #95, and #96 have the relevant people to talk to.

[11:17:31.0000] <jugglinmike>
because it seems to me like there already is a cache--it's just defined very informally

[11:18:02.0000] <jugglinmike>
and the way we're considering interacting with it in this WebDriver patch kind of forces that issue

[11:19:07.0000] <jugglinmike>
We're basically saying, "update the cache" but wording it in such a way that an implementor looking at one part of the spec would never suspect its usage in another

[11:19:14.0000] <jyasskin>
It's informal because it's slightly different for each browser. https://github.com/w3c/permissions/pull/151#discussion_r140614720 has a brief summary of how browsers differ here, and I think one of those PRs has my more detailed investigation.

[11:20:30.0000] <jugglinmike>
Oh, right. I was reading that in the context of "realms," but now I see that you were describing the caching mechanisms

[11:20:58.0000] <jyasskin>
WebDriver can (hopefully) set the browser to a "testing" mode that matches the "testing" mode of all other browsers, but, for example, Firefox's default mode never saves a permission response at all, which definitely doesn't work for the proactive model you're aiming at.

[11:23:48.0000] <jugglinmike>
What do you think about formalizing the informality? In other words, something like, "The user agent MAY cache requests to read the state for a given descriptor and environment settings object, but this cache must be invalidated by "Set Permission"

[11:24:32.0000] <jugglinmike>
with similar text accompanying the new WebDriver "Set Permission" command

[11:24:46.0000] <jyasskin>
This is a difference between your "cache" change and my attempts to define a "store". Are you thinking that an un-cached permission state gets fetched from the user?

[11:25:44.0000] <jyasskin>
Hm, no, because then "Set Permission" would be forcing something into the cache instead of invalidating the entry there...

[11:26:11.0000] <jugglinmike>
I think so, but I'm still hazy on the details. That's because I don't fully understand the text "and the UA has not received new information about the user's intent"

[11:27:12.0000] <jugglinmike>
That seems a little unbounded. Would it be fair to add "...about Permissions Descriptor |x| and environment settings object |y|" ?

[11:27:57.0000] <jyasskin>
Ah, yes, I think that won't break anything.

[11:28:11.0000] <jugglinmike>
Because trying to formalize the cache makes it seem like any "new information about the user's intent" would clear the entire cache

[11:29:32.0000] <jyasskin>
Mhmm. Now, a browser *is* free to treat the user clearing the geolocation permission on one tab as information about their intent for the notifications permission on another tab, or even another origin.

[11:30:03.0000] <jyasskin>
The note about implicit signals in https://w3c.github.io/permissions/#new-information-about-the-users-intent says to be cautious about that.

[11:32:11.0000] <jugglinmike>
Oh! I think I missed that since it landed since I started this patch. I ought to re-read the spec from top to bottom. Sorry about that

[11:32:28.0000] <jyasskin>
No worries. :)

[11:33:59.0000] <jugglinmike>
I may be over-thinking this now, but I'm starting to get confused about the difference between "the user's intent" and "the UA's interpretation of the user's intent"

[11:36:28.0000] <jugglinmike>
In the example you shared, it seems like you could argue that you've only received information about the user's intent for the geolocation permission. Though i wouldn't make that argument myself.

[11:37:00.0000] <jugglinmike>
So maybe that's too pedantic

[11:38:23.0000] <jyasskin>
:) Everything here is about the UA's interpretation of the user's intent. One particular example where that's important is when *other* users flag a site as spammy or hostile, Chrome wants to be able to revoke your grant of the permission, on the theory that you intend to avoid spammy or hostile sites but might not have realized when you granted this particular site permission.

[11:38:58.0000] <jyasskin>
(We don't do this today, unless something's changed, but it's something the permissions spec should allow in the future.)

[11:40:30.0000] <jyasskin>
jugglinmike: So, even when I was modeling this as a store, there was blanket permission for the browser to change the store at almost any time.

[11:47:22.0000] <jugglinmike>
sorry jyasskin, I dropped again. I've switched to a wired connection

[11:47:33.0000] <jyasskin>
jugglinmike: What's my last message you saw?

[11:47:45.0000] <jugglinmike>
>  jugglinmike: So, even when I was modeling this as a store, there was blanket permission for the browser to change the store at almost any time.

[11:47:51.0000] <jyasskin>
That was my last message. :)

[11:48:04.0000] <jugglinmike>
great

[11:49:31.0000] <jugglinmike>
Your comment makes it sound like "forcing something into the cache" is a deal-breaker, but as I understand it, that is exactly what Set Permissions needs to be doing

[11:50:32.0000] <jugglinmike>
because when you say, "invalidating the entry there" as an alternative, I'm wondering what would happen if that was all that "Set Permission" could do

[11:52:08.0000] <jyasskin>
I think that your current wording in https://pr-preview.s3.amazonaws.com/bocoup/permissions/pull/151.html#set-permission-command should be implementable for all the browsers, and will in practice cause the automation to work when there's no human also poking at the browser to make it stop working.

[11:53:04.0000] <jugglinmike>
Okay, then maybe I should just drop it :)

[11:59:50.0000] <jyasskin>
jugglinmike: It's not that your concern is wrong: your text doesn't *require* the browser to do the right thing, and maybe someone will complain about it in the future. I just don't think it's worth spending a lot of time on it now.

[12:01:20.0000] <jugglinmike>
Understood. I appreciate your input--I'm in no position to prioritize things like this

[12:01:57.0000] <jyasskin>
I mean, I'm not really the final authority either, but if I were, your text would already be good enough. :)

[12:05:18.0000] <jugglinmike>
If only :P

[12:06:22.0000] <jyasskin>
jugglinmike: If I were to try to fix this, I'd probably try to nail down the "testing" mode, where the browser isn't allowed to take user input into account, and it always persists permissions, and then say that browsers only need to use that mode when WebDriver tells them to. But again, only if this matters to you or someone wants to veto the change without it, and you want to corral the Mozilla folks who objected

[12:06:22.0000] <jyasskin>
last time.

[12:06:47.0000] <jyasskin>
Ok, I'm running off to lunch. Let me know if any other questions come up.

[12:06:54.0000] <jugglinmike>
jyasskin: Could you give me a little guidance on how to allow the UA to reject requests? Should it be as specific as describing the case of setting an always-on permission to "denied"

[12:07:32.0000] <jugglinmike>
Or should it just say, "If the UA doesn't like the looks of the request, return a WebDriver error"

[12:07:56.0000] <jyasskin>
jugglinmike: I would probably use the second unless there's a reason to restrict UAs more than that.

[12:08:38.0000] <jugglinmike>
Okay then

[12:08:41.0000] <jyasskin>
There could be a note giving the example of denying always-on permissions, but I bet someone will come up with another time they can't munge the permission.

[12:08:50.0000] <jugglinmike>
So here's my plan for today

[12:11:14.0000] <jugglinmike>
1- Extend the step "Interpret parameters.state as if it were the result of an invocation of permission state" to occur inside a task (and update the algorithm to wait for all such tasks to complete) 2- add a provision to allow the UA to initially reject the request if they can't honor it (for whatever reason)

[12:11:19.0000] <jugglinmike>
Does that sound right to you?

[12:12:03.0000] <jyasskin>
Yep, sounds great.

[12:12:25.0000] <jugglinmike>
Excellent

[12:12:32.0000] <jugglinmike>
Thanks for your time today, jyasskin

[12:12:40.0000] <jyasskin>
No problem. :)

[12:12:43.0000] <jugglinmike>
Have a good lunch!

[12:23:32.0000] <jsbell>
Thought I got pinged here but maybe not. Searching the logs, though...

[12:24:15.0000] <jsbell>
othermaciej: new TextDecoder('windows-949').encoding === "euc-kr"

[12:25:09.0000] <jsbell>
Not sure that was the question (from Nov 6th) though. :)

[12:26:29.0000] <jsbell>
You can also load a page w/ <meta charset=windows-949> and inspect its document.characterSet (again, not sure that was the question)

[12:27:51.0000] <othermaciej>
jsbell: I don't know what question that would be the answer to

[12:28:30.0000] <jsbell>
othermaciej: https://freenode.logbot.info/whatwg/20171106#c1367176

[12:29:57.0000] <jsbell>
I have partial answers for some of the other encoding questions that came up in that discussion but it may all be moot now. Feel free to re-ask.

[15:15:41.0000] <TimothyGu>
Domenic: re the Object.prototype.toString issue, V8 has this API called v8::FunctionTemplate::SetClassName that defines the behavior: https://v8.paulfryzel.com/docs/master/classv8_1_1_function_template.html#a491e77dc7ceb5b0fe75880d11f2dbe9e

[15:16:48.0000] <TimothyGu>
I'm guessing Chrome's IDL class generator uses this function, which leads to the issue you filed

[15:17:57.0000] <TimothyGu>
but not only does it govern the toString behavior, the function also sets the "name" property of the constructor function

[15:19:50.0000] <TimothyGu>
which means that in short, it should be a V8 issue to make SetClassName() only change the name of the constructor function and not any toString behavior

[15:20:14.0000] <Domenic>
TimothyGu: nice detective work. Yeah, we'll see how they come down... I hope it gets straightened out.

[15:20:32.0000] <jsbell>
TimothyGu: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/V8DOMConfiguration.cpp?type=cs&q=V8DOMConfiguration.cpp&sq=package:chromium&l=727 might be informative (that's where it's used by the bindings code)

[15:21:22.0000] <TimothyGu>
jsbell: thanks for the link. I think the binding code looks right

[15:22:56.0000] <TimothyGu>
v8::FunctionTemplate::SetClassName() sets the internal class_name property in the FunctionTemplate, which is then used by FunctionTemplateInfo::GetOrCreateSharedFunctionInfo in https://cs.chromium.org/chromium/src/v8/src/objects.cc?type=cs&q=objects.cc&sq=package:chromium&l=1308

[15:23:49.0000] <TimothyGu>
it uses it in two ways as I mentioned: 1. as the name of the function (https://cs.chromium.org/chromium/src/v8/src/objects.cc?type=cs&q=objects.cc&sq=package:chromium&l=1335) and as the [[Class]] internal slot (https://cs.chromium.org/chromium/src/v8/src/objects.cc?type=cs&q=objects.cc&sq=package:chromium&l=1342)

[15:25:23.0000] <TimothyGu>
then this [[Class]] internal slot gets picked up in the CodeStubAssembler::ClassOf() (https://cs.chromium.org/chromium/src/v8/src/code-stub-assembler.cc?type=cs&sq=package:chromium&l=9724), which is itself called by Object.prototype.toString (https://cs.chromium.org/chromium/src/v8/src/builtins/builtins-object-gen.cc?type=cs&sq=package:chromium&l=355)

[15:25:41.0000] <TimothyGu>
thats about it


2017-12-09
[19:16:47.0000] <Domenic>
tobie: in https://github.com/whatwg/html/pull/3273 pushing new commits doesn't seem to update the PR preview

[10:05:35.0000] <annevk>
Domenic: that looks ok now? Usually takes a while due to all the scripts

[10:06:05.0000] <annevk>
Domenic: I guess ideally it would mention which commit it reflects


2017-12-10
[06:19:07.0000] <nox>
annevk: https://github.com/servo/servo/pull/19461#discussion_r155932279

[06:19:35.0000] <nox>
Is it expected for these tests to even use 'for (const …)'?

[06:22:25.0000] <annevk>
nox: sure, web-platform-tests is not constrained when it comes to JS syntax

[06:23:03.0000] <nox>
annevk: Asked because I remembered making some tests more portable in the past, because of some unsupported features in Safari.

[06:24:54.0000] <annevk>
nox: I think it’s considered acceptable to rewrite if not too much of a concession in readability

[06:25:40.0000] <nox>
annevk: Thanks! Quoted you in a reply.

[06:29:06.0000] <annevk>
nox: it’d be good to figure out a better SpiderMonkey embedding story as this keeps coming up in a various ways and confusing folks

[06:29:23.0000] <annevk>
nox: would be nice to address the root cause

[06:29:41.0000] <nox>
annevk: Indeed.

[06:29:52.0000] <nox>
annevk: SMUP has been blocked for almost a year though.

[06:29:56.0000] <nox>
:(

[06:30:03.0000] <annevk>
UP?

[06:30:22.0000] <nox>
annevk: Like rustup, but for spidermonkey.

[06:31:05.0000] <nox>
Like a rustup* Not the tool, but the action of updating Rust somewhere.

[06:31:16.0000] <annevk>
Hah, don’t know that one either

[06:31:20.0000] <nox>
I should remember slang is not very portable from one channel to another. :)

[06:31:22.0000] <annevk>
I see

[06:31:44.0000] <nox>
annevk: As the linked discussion shows, we can also just copy the test in _mozilla anyway.

[10:22:45.0000] <Domenic>
It's a start /cc annevk https://github.com/jsdom/data-url

[10:24:33.0000] <annevk>
Domenic: cool, will look sometime next week

[15:51:24.0000] <TimothyGu>
tobie: hey, independent of the PR, is a user-created function a user object or a platform object?

[15:51:51.0000] <tobie>
a user object

[15:52:00.0000] <tobie>
(I think)

[15:53:30.0000] <TimothyGu>
tobie: how about undefined?

[15:54:01.0000] <tobie>
that's an ES thingy, no?

[15:54:09.0000] <tobie>
Whatever these are called nowadays.

[15:54:50.0000] <tobie>
TimothyGu: might depend whether you're in strict mode or not?

[15:55:18.0000] <TimothyGu>
how?

[15:55:45.0000] <TimothyGu>
as in, 3.9 currently says "Otherwise, the interface is not a single operation callback interface. Any object is considered to implement the interface."

[15:56:30.0000] <TimothyGu>
it's not "any Object" which would make things unambiguous

[15:57:35.0000] <tobie>
1:00am here, there's no way I'm able to even think about that. :D

[15:57:51.0000] <TimothyGu>
:)

[15:58:18.0000] <tobie>
For those of you who want internal slots in WebIDL, here's a proposal in the form of a rough PR: https://github.com/heycam/webidl/pull/495

[15:59:49.0000] <tobie>
annevk: "Domenic: I guess ideally it would mention which commit it reflects" <-- it does when you hover over it.


2017-12-11
[16:00:14.0000] <tobie>
annevk: We could tweak the UI to make that clearer.

[16:00:18.0000] <tobie>
annevk: LMK

[16:01:25.0000] <tobie>
smaug____: internal slots proposal ^

[20:33:08.0000] <annevk>
SimonSapin: did you see http://ucsx.org/?

[20:33:27.0000] <SimonSapin>
annevk: I did

[20:35:00.0000] <SimonSapin>
annevk: I think it’s interesting as "solving a math problem". For character encodings though: I’m not convinced we’re gonna need to go beyond U+10FFFF or a very long time 2. if we do, we should pick one extension not 9

[20:35:10.0000] <SimonSapin>
for* a very long time

[20:35:28.0000] <annevk>
Yeah

[20:35:38.0000] <SimonSapin>
(I want to say "ever", but this kind of prediction tends to be wrong)

[20:36:12.0000] <annevk>
Gonna need something bigger than a couple emoji each year

[20:39:35.0000] <othermaciej_>
lol, UCS-∞

[20:58:02.0000] <SimonSapin>
the most code-space-consuming thing I imaging we might want to do (regardless of how feasible it is now) is undoing Han unification, but even that is like 3× it most?

[20:58:14.0000] <SimonSapin>
and Unicode 10.0 is at ~8%

[21:03:40.0000] <SimonSapin>
also interesting that in 16-bit variants, UCSX encodes new values as sequences that are unpaired surrogates in UTF-16, so it’s unclear how that would work in WTF-16 systems like JS

[21:14:14.0000] <annevk>
JS would need a new string type basically

[21:22:04.0000] <othermaciej_>
maybe the new string type could be one of the UTF-8 based variants, then

[06:35:17.0000] <tobie>
This is probably a question I should have the answer to, but where do I find how the object that implements an interface with the [Global] extended attribute is initialized?

[06:37:10.0000] <tobie>
Does it simply follow the |steps| defined in the algorithm in https://heycam.github.io/webidl/#interface-object ?

[06:39:59.0000] <tobie>
I'm trying to ES-ify the exposition of attributes, constants and operations (see: https://pr-preview.s3.amazonaws.com/tobie/webidl/pull/494.html#es-constants).

[06:41:01.0000] <tobie>
And I'm having trouble with how to expose those "on the single object that implements the interface, when an interface is declared with the [Global] extended attribute."

[06:41:11.0000] <tobie>
Domenic, annevk: ^

[07:25:20.0000] <Ms2ger>
tobie, do you have any algorithm for creating platform objects?

[07:27:49.0000] <tobie>
Ms2ger: yes, |steps| in the algorithm found in https://heycam.github.io/webidl/#interface-object is the closest I can think of.

[07:28:35.0000] <Ms2ger>
No, that's the interface objects

[07:29:25.0000] <Ms2ger>
I think it makes most sense to have an algoritm to create instances, and then define the constants and whatever there, depending on its interface being marked with [Global]

[07:32:41.0000] <tobie>
Ms2ger: I;m talking about the value of the steps variable within that algorithm

[07:33:35.0000] <Ms2ger>
Oh, you're right

[07:34:03.0000] <tobie>
Ms2ger: maybe it should be it's own algorithm.

[07:34:05.0000] <tobie>
:D

[07:34:11.0000] <tobie>
its

[07:35:07.0000] <Ms2ger>
Or in https://heycam.github.io/webidl/#es-interface ... But you have to make sure that you don't create multiple JS objects for one IDL object...

[07:35:11.0000] <Ms2ger>
Not sure

[08:09:18.0000] <annevk>
FYI: https://blog.whatwg.org/working-mode-changes

[08:12:49.0000] <nox>
PogChamp

[08:35:25.0000] <gsnedders>
annevk: Wow. There's a part of me amazed it's finally happened.

[08:38:43.0000] <wanderview>
annevk++

[09:02:38.0000] <Domenic>
The real question is which of our fine individual contributors is going to be the first to sign the new agreement thingy. (And hopefully not break my code.)

[09:03:31.0000] <annevk>
Sounds like a challenge

[09:29:36.0000] <Domenic>
I wonder if anyone even realizes that the blog has a comments feature anymore.

[09:34:39.0000] <annevk>
Domenic: there was a spammy comment I trashed (since not sure if actually spam)

[09:37:26.0000] <Domenic>
We have a winner! domfarolino in https://github.com/whatwg/participant-data/commit/c3e0d4f4d6d1bbddd406f5ddb8b29928a0ab46ab . Nothing seems to have broken!

[09:37:42.0000] <gsnedders>
Domenic: Can I do a Philip`?

[09:38:15.0000] <gsnedders>
(i.e., try obscure Unicode characters likely to break things)

[09:38:52.0000] <Domenic>
gsnedders: hmm, since clearing crap from the database is a bit annoying, let me set up a staging server/data repo for that first. I need to do that anyway to test any changes.

[09:41:24.0000] <gsnedders>
Domenic: I was (mostly) joking.

[09:41:39.0000] <gsnedders>
I tend not to do such things with legal forms

[09:42:09.0000] <Domenic>
It's a good idea though.

[10:17:42.0000] <domfarolino>
Domenic: \o/

[10:29:54.0000] <domfarolino>
Domenic: annevk: So if I understand this correctly, only the Work Stream editors (editors officially approved/appointed by SG) appear in the WorkStream.md file in whatwg/sg (and are responsible for all Living Standards in a Work Stream), and deputy editors and other contributors to Living Standards appear in the ACKs of said standards?

[10:31:03.0000] <Domenic>
domfarolino: that's the idea. Workstream Editors are the ones "on the hook" for any process. Whereas there can be many editors or deputy editors or whatever for a given standard.

[10:31:38.0000] <Domenic>
Workstream Editor is mostly a service role, not necessarily "senior" or "most involved" or anything.

[10:34:41.0000] <wanderview>
after today's announcement, does anything change with how html spec is being edited in both whatwg and w3c?  I've seen some tweet that maybe it has, but it seems like its up to w3c to make that decision

[10:35:08.0000] <domfarolino>
Domenic: Excellent thanks!

[10:35:54.0000] <annevk>
wanderview: yeah, that'd be up to the W3C

[10:36:41.0000] <annevk>
wanderview: though I suspect browsers have less incentive to contribute there now

[10:37:11.0000] <wanderview>
annevk: I was just curious because of discussion at TPAC about moving workers back into w3c html and w3c html spec getting a new editor

[11:16:15.0000] <annevk>
kochi: happy to move to two days if that's better for the F2F

[11:16:34.0000] <annevk>
kochi: I suspect I'll be around for a few more days though to make it worth the length of the trip

[11:35:05.0000] <Domenic>
tobie: I think those are the steps for now. The last paragraph of https://github.com/heycam/webidl/issues/467 seems relevant too.

[11:40:01.0000] <tobie>
Domenic: basically I need a hook to define props directly on the instance for [Global] and unforgeable.

[11:40:32.0000] <Domenic>
tobie: I see. For [Unforgeable] I guess it's part of "create an X object" which is still undefined

[11:41:22.0000] <Domenic>
For globals maybe we need a separate algorithm for creating the global instances, yeah.

[11:41:40.0000] <Domenic>
Seems OK to leave those imprecise with a big TODO/warning in the spec that they are not in the imperative algorithm yet, just to chunk up the work.

[11:43:26.0000] <annevk>
Oooh, we're gonna define allocating objects? Yay

[11:43:43.0000] <Domenic>
It's always been the plan

[11:44:04.0000] <annevk>
Now I remember why I wanted typed slots

[11:44:25.0000] <annevk>
So that when you allocate a Document, IDL could take of allocating the DOMImplementation object

[11:44:34.0000] <annevk>
take care*

[11:44:52.0000] <annevk>
And also take care of the global for that and such

[11:45:25.0000] <annevk>
Basically for any kind of tear-off setup it's nice when IDL can take over stuff

[11:45:42.0000] <annevk>
But maybe we should just have something dedicated for that

[11:45:50.0000] <tobie>
As a matter of fact, slots "allocation" also needs to happen somewhere there

[11:46:25.0000] <annevk>
Yeah that's nice, that way you can't change slots later on

[11:46:41.0000] <annevk>
(you can still change their values of course)

[11:46:46.0000] <annevk>
(but not the object layout)

[11:46:53.0000] <TabAtkins>
Domenic: Y'all are gonna want some boilerplate changes for WHATWG stuff, yeah?

[11:47:45.0000] <annevk>
TabAtkins: aye, though it need not be completed today and I think mostly depends on us doing some work

[11:48:00.0000] <TabAtkins>
I can at least get y'all's copyright in order, I guess.

[11:48:25.0000] <annevk>
TabAtkins: well, even that we manage manually today

[11:48:57.0000] <annevk>
TabAtkins: so would have to be paired with changes against all standards using Bikeshed

[11:48:58.0000] <TabAtkins>
I'll leave the Review Drafts boilerplate until someone actually needs one.

[11:49:39.0000] <annevk>
Anyway, I should let Domenic coordinate this since I'm about to land

[12:17:10.0000] <Domenic>
TabAtkins: my plan is to give it another go at templating all our stuff now that you added metadata generation and ordering.

[12:17:17.0000] <TabAtkins>
+1

[12:17:30.0000] <TabAtkins>
Stress test the thing and file issues if anything seems wrong or insufficient, as always.

[12:51:07.0000] <tobie>
Alright, added a TL;DR to the slots proposal: https://github.com/heycam/webidl/pull/495

[13:01:44.0000] <othermaciej>
Yay, our first post-launch PR for the policy documents (ok, not a very big one, but still glad to be working in the open on this kind of stuff)

[13:01:59.0000] <othermaciej>
https://github.com/whatwg/sg/pull/43

[14:45:52.0000] <TabAtkins>
Hehehe


2017-12-12
[17:16:18.0000] <astearns>
Did Tab submit the appropriate workstream participation agreement before submitting his PR?

[18:25:50.0000] <TabAtkins>
I'm a member of Google, I'm cool. ^_^

[18:26:15.0000] <othermaciej_>
Google's agreement covrers him, but also technically the agreement is not mandatory until Jan 11, 2018

[18:26:27.0000] <othermaciej_>
(grace period in case people need their laywers to review, etc)

[21:31:35.0000] <xfq>
https://whatwg.org/ipr-policy#71-copyright-license-for-whatwg-publications

[21:31:36.0000] <xfq>
so https://github.com/whatwg/dom/blob/master/LICENSE and friends may need updating?

[21:45:04.0000] <annevk>
xfq: yeah, see Bikeshed discussion earlier today

[21:45:42.0000] <annevk>
xfq: we’ll get everything in order over the next couple of weeks

[21:50:36.0000] <xfq>
annevk: you mean, the discussion in #whatwg?

[21:50:58.0000] <annevk>
Yeah

[21:51:01.0000] <xfq>
annevk: ok, thanks for the hint!

[01:19:48.0000] <foolip>
MikeSmith: I love https://validator.w3.org/checklink, is there a way one could run that from Travis?

[01:20:09.0000] <foolip>
Or perhaps just as a daily cron job, in any case automated.

[01:20:44.0000] <MikeSmith>
it doesn’t handle fragment IDs that are resolved by JavaScript

[01:20:53.0000] <MikeSmith>
on the client side

[01:21:54.0000] <MikeSmith>
so it reports many false positives for broken links

[01:33:09.0000] <foolip>
MikeSmith: ok, that's a tricky problem...

[01:33:15.0000] <foolip>
MikeSmith: speedy review of https://github.com/whatwg/whatwg.org/pull/128?

[01:34:04.0000] <foolip>
I could write a custom checker thing with node that just collects URLs and checks for 404s, but not feeling quite that ambitious today.

[01:58:25.0000] <MikeSmith>
foolip: reviewed and merged

[01:59:31.0000] <foolip>
MikeSmith: thanks!

[04:34:25.0000] <annevk>
Hmm, fragment IDs resolved by JS would normally be considered an error

[04:34:55.0000] <annevk>
We only have that as fallback in HTML for old links we expect to be updated

[04:35:18.0000] <annevk>
Though we also use it as a trick sometimes I suppose

[04:35:37.0000] <foolip>
ReSpec specs do it too

[04:35:52.0000] <foolip>
And I was talking about outgoing links too

[04:37:26.0000] <annevk>
ReSpec should just generate the final link

[04:38:08.0000] <annevk>
Sending readers through any kind of additional hop is bad, unless there is a very good reason I suppose

[04:39:28.0000] <foolip>
ReSpec generates in the browser, so...

[04:40:03.0000] <foolip>
Most specs at least, WebVTT had a pre-generated one, but that was ages ago

[04:48:19.0000] <foolip>
botie: what can you do?

[04:48:19.0000] <botie>
wish i knew, foolip

[04:48:26.0000] <foolip>
botie: help?

[04:52:35.0000] <foolip>
print.pdf is broken and trying to get it working locally got into other problems, so: https://github.com/whatwg/html-build/pull/134

[05:13:14.0000] <annevk>
foolip: seems we can wait a little longer to get an update from the person upstream?

[05:13:18.0000] <annevk>
(forgot their name, sorry)

[05:21:31.0000] <foolip>
annevk: sure

[07:23:56.0000] <Domenic>
foolip: annevk: MikeSmith: seems like we could maybe run checklink on whatwg.org, if not yet on the HTML spec?

[08:14:08.0000] <Domenic>
If anyone has thoughts on spec algorithm style, especially async spec algorithms, point them this way. https://github.com/whatwg/infra/issues/181 . I'm going to tag JakeA based on a hunch he would have opinions.

[08:15:06.0000] <annevk>
Yeah, checklink should work for all WHATWG standards

[08:15:22.0000] <annevk>
Even HTML I’d think

[08:15:37.0000] <annevk>
If we have the ReSpec bug that seems bad

[08:16:24.0000] <Domenic>
The problem is links *to* ReSpec specs

[08:18:19.0000] <annevk>
Oh

[08:18:21.0000] <annevk>
Sigh

[08:18:40.0000] <annevk>
Can we filter results?

[08:18:59.0000] <annevk>
Build a database of bad specs

[08:24:21.0000] <wanderview>
annevk: aren't you supposed to be in some kind of meeting?

[08:25:51.0000] <annevk>
wanderview: yeah… I’m there.

[08:27:04.0000] <wanderview>
annevk: I'm watching via twitter

[08:28:00.0000] <annevk>
👍

[08:34:05.0000] <JakeA>
Domenic: I hadn't noticed this use of "asynchronously" before, but I can't figure out what the difference is between that and "in parallel", except that is has a return value. Is that the difference?

[08:42:18.0000] <Domenic>
JakeA: good question. I guess the idea is that "in parallel" is the technology behind async algorithms. E.g. "in parallel" is how you actually do the work, but async algorithms is a convention for writing algorithms that do such work. I dunno, that doesn't sound clearer...

[08:42:38.0000] <Domenic>
JakeA: so concretely, the "in parallel"ness of the #fetching-scripts algorithms is hidden behind the calls to fetch

[08:42:44.0000] <Domenic>
But that's like four levels deep and in other spec

[08:43:04.0000] <Domenic>
So we need something to say in the HTML spec and in those four levels that indicates that this algorithm won't complete synchronously.

[08:44:27.0000] <JakeA>
Domenic: I tend to just write algorithms to be synchronous, then go "in parallel" at the top level

[08:46:21.0000] <Domenic>
Right, I guess that's usually a good option, but doesn't work for fetching-scripts because we need to do multiple fetches at the same time. Maybe?

[08:48:11.0000] <JakeA>
Domenic: in that case I go "in parallel" to express parallelism, but have something that waits for all those threads to complete. But yeah, I don't know if that's the best.

[08:48:53.0000] <JakeA>
Domenic: eg steps 7 & 8 in https://wicg.github.io/background-fetch/#attempt-a-background-fetch

[08:50:12.0000] <JakeA>
But using "wait for" in specs always makes me unsure

[08:50:36.0000] <JakeA>
(btw there are lots of type & realm issues in that draft that I now understand, don't judge me)

[08:58:25.0000] <wanderview>
JakeA: is there something like `async function()` for specs?

[08:58:53.0000] <wanderview>
I guess that implies there must be an event queue, etc

[08:59:12.0000] <wanderview>
at least in gecko, though, we do always have an event queue for every thread

[09:11:52.0000] <Domenic>
JakeA: yeah I guess the problem I see is that per the letter of that spec you linked, I'd expect a server to never see multiple requests at the same time. "For each" is sequential.

[09:15:38.0000] <Domenic>
JakeA: oh, but the example you dropped in the issue is much clearer.

[09:15:50.0000] <Domenic>
Right, nevermind, I was just wrong.

[09:15:55.0000] <Domenic>
background fetch is fine

[09:16:18.0000] <Domenic>
"run the following steps in parallel" != "run the following steps in parallel and wait for them to finish before moving on the next step"

[09:16:34.0000] <JakeA>
Domenic: yeah, I've been wondering if that isn't so clear

[09:17:42.0000] <JakeA>
wanderview: maybe related, the "parallel queue" thing might help https://html.spec.whatwg.org/multipage/infrastructure.html#parallel-queue

[09:21:47.0000] <wanderview>
JakeA: does "parallel queue" have an `await` equivalent?

[09:22:50.0000] <JakeA>
wanderview: hm, not really. It's probably unrelated

[09:23:30.0000] <wanderview>
JakeA: but, thats kind of what we want right?  the ability to write steps like an async funciton where we can await something without blocking the thread

[09:26:38.0000] <JakeA>
wanderview: I dunno, isn't it simpler to just go "in parallel" then be sync there?

[09:26:55.0000] <JakeA>
wanderview: I tried to cover this at https://github.com/whatwg/infra/issues/181#issuecomment-351117956

[09:28:34.0000] <wanderview>
JakeA: I guess if "wait for X to happen" in an "in parallel" section allows other async stuff to happen in that thread, then I guess it does what I want... "wait for X to happen" is like `await` to me

[09:52:09.0000] <MikeSmith>
Domenic: yeah we could run the link checker on anything at least that we trust isn’t generating anchors with JavaScript

[09:53:48.0000] <MikeSmith>
foolip: the way botie works is like this:

[09:54:20.0000] <MikeSmith>
botie, inform zcorpan I left his message for you to show foolip how botie works

[09:54:20.0000] <botie>
will do

[09:55:07.0000] <MikeSmith>
then when zcorpan joins, botie will say that message

[09:59:05.0000] <foolip>
Oh. But I'm always connected :)

[10:18:31.0000] <MikeSmith>
foolip: yeah, botie is useful for others who aren’t always connected

[10:18:45.0000] <MikeSmith>
ah btw, when botie says that message it will mention your nick too

[10:19:14.0000] <MikeSmith>
so you will get some kind of notification in your IRC client when he joins

[10:20:29.0000] <MikeSmith>
the format of the botie messages is, “zcorpan, at [some timestamp] MikeSmith said, I left his message for you to show foolip how botie works”

[10:49:42.0000] <botie>
zcorpan, at 2017-12-12 17:54 UTC, MikeSmith said: I left his message for you to show foolip how botie works

[12:05:27.0000] <annevk>
MikeSmith: could you maybe document botie on the IRC wiki page? Or tell me enough to do it

[12:10:32.0000] <Domenic>
I'm surprised https://validator.w3.org/checklink doesn't have an option to just not check the fragments actually.

[12:12:32.0000] <foolip>
I suppose one could apply a filter to the output, if one can get it as text

[13:15:26.0000] <MikeSmith>
Domenic: thanks for merging the Web-storage domintro PR

[13:15:33.0000] <MikeSmith>
and updating the commit message

[13:16:04.0000] <Domenic>
MikeSmith: for sure, sorry I've been so busy lately. Hoping to get to your SSE PR today

[13:17:07.0000] <MikeSmith>
I’d meant to get back to both of those before now, but neither had risen up the priority stack yet

[13:17:32.0000] <MikeSmith>
working on the CSS checker integration has taken a lot of time

[13:17:46.0000] <MikeSmith>
mostly me fixing things I regressed :)

[13:18:10.0000] <Domenic>
:) still it'll be a neat feature for developers I think

[13:18:19.0000] <MikeSmith>
yeah for sure

[13:19:15.0000] <MikeSmith>
one side effect of some related changes I made to the CSS checker code itself recently is that I think we’ll be able to produce a standalone css-validator.jar similar to the HTML checker vnu.jar

[13:19:26.0000] <MikeSmith>
that can be integrated into to CI etc

[13:19:59.0000] <MikeSmith>
for checking .css files, not just for embedded <style> contents

[13:20:53.0000] <Domenic>
Oh excellent

[13:40:21.0000] <MikeSmith>
wonder where TabAtkins is at on making a standalone syntax highlighter

[13:41:10.0000] <MikeSmith>
I think I have the wattsi code ready to just plug that in as soon as it’s available

[13:42:14.0000] <MikeSmith>
I’m curious how fast that syntax-highlighter script will prove to be

[13:43:07.0000] <MikeSmith>
it needs to be called and run about 3000 times during each build...

[14:55:26.0000] <TabAtkins>
I'll finish it over vacation, sorry for the delay. It's 90% done. ^_^

[15:00:44.0000] <jyasskin>
TabAtkins: No working over vacations.

[15:25:17.0000] <annevk>
Domenic: we need some kind of label for things that got merged without agreement across implementers

[15:25:24.0000] <annevk>
Domenic: e.g., history.index

[15:25:34.0000] <annevk>
Domenic: and maybe revert after some period

[15:25:53.0000] <Domenic>
annevk: that had agreement. It should probably get reverted though as Chrome and Safari have not shipped it as they said they would.

[15:26:02.0000] <annevk>
Domenic: does give credence to you insisting on explicit approval

[15:26:36.0000] <Domenic>
I would approve a PR that reverts it. It's on my to-do list.

[15:26:48.0000] <annevk>
Domenic: ah yes, you're right


2017-12-13
[17:10:58.0000] <MikeSmith>
TabAtkins: when I run bikeshed remotely on a file, it doesn’t emit the meta[name="document-revision"] output in teh generated HTML?

[17:13:39.0000] <MikeSmith>
https://stackoverflow.com/questions/47783781/if-no-cors-can-lead-to-ddos-anyways-for-what-reasons-can-non-credentialed-fe

[17:14:17.0000] <MikeSmith>
annevk: 👆⬆

[18:39:57.0000] <TabAtkins>
MikeSmith: That would be because you're running it remotely; that is, not on a file within a github repo. The server just sees bits; it has no idea what revision your local git repo considers those bits to be a part of.

[18:40:18.0000] <MikeSmith>
ah

[20:39:34.0000] <annevk>
MikeSmith: the intranet response is correct

[20:40:02.0000] <annevk>
MikeSmith: did you see my documenting botie question?

[20:41:15.0000] <MikeSmith>
annevk: yeah I think Simon updated it already

[20:42:19.0000] <MikeSmith>
yeah https://wiki.whatwg.org/wiki/IRC#Bots

[20:42:39.0000] <annevk>
Great

[21:59:36.0000] <othermaciej_>
Fairly positive (if mildly confused) blog post about the recent changes: https://love2dev.com/blog/whatwg-adopts-standards/

[23:06:08.0000] <foolip>
Domenic: on "we need some kind of label for things that got merged without agreement across implementers" I'm going to explore that space soon by looking at new failing tests that stay failing, hoping to be able to formalize and automate if I find a lot of interesting stuff manually

[23:07:31.0000] <foolip>
Domenic: next steps in testing feedback loop that is. Any ideas beyond "explore the space" welcome. Plan is to go poking as the one case a week and see what I learn in Q1

[23:07:38.0000] <foolip>
annevk: ^

[03:10:30.0000] <foolip>
RFC: https://github.com/whatwg/html/issues/1849

[03:11:04.0000] <foolip>
Ooops, I mean https://github.com/whatwg/html/issues/1849#issuecomment-351359904, asking for feedback on "testing feedback loop", basically.

[03:23:12.0000] <annevk>
foolip: seems pretty good

[03:23:39.0000] <annevk>
foolip: tooling for filing bugs against all implementations or a subset would be rather nice though

[03:24:22.0000] <annevk>
foolip: especially with all the different interfaces implementations use and some of them being somewhat slow to use

[06:16:28.0000] <foolip>
annevk: interesting. Domenic was skeptical about that because each engine's bug might be different, but maybe it is worth experimenting with.

[06:30:11.0000] <smaug____>
what do asserts mean in a spec?

[06:30:41.0000] <Mek>
smaug____: https://infra.spec.whatwg.org/#assertions

[07:05:15.0000] <Domenic>
My only gripe with that article is https://whatwg.org/faq#spell-and-pronounce but otherwise seems reasonable :)

[08:10:08.0000] <annevk>
foolip: I often copy-and-paste

[08:23:29.0000] <Domenic>
I try to tailor my bugs to what tests are failing in each engine, but I guess that's not crucial.

[08:24:08.0000] <annevk>
Domenic: I should probably check with you first

[08:24:23.0000] <annevk>
Domenic: but how would document.on("click").first().then(e => …) work with preventDefault()?

[08:24:32.0000] <Domenic>
annevk: ah, yeah, first() will break it

[08:24:58.0000] <annevk>
Okay, so I guess most of the other stuff runs sync?

[08:25:15.0000] <annevk>
sync is really confusing term, I guess I should say immediately

[08:25:41.0000] <Domenic>
Right, the promise-returning ones get delayed by the promise machinery, but the combinators and subscribe run sync.

[08:25:54.0000] <annevk>
Okay

[08:26:01.0000] <Domenic>
Well, the promise-returning ones call their callbacks synchronously, e.g. forEach(cb) or reduce(cb), but the promise returned is async...

[08:26:11.0000] <Domenic>
forEach(cb).then(f, r) will run cb sync but f/r async

[11:43:30.0000] <foolip>
Good news all, DigitalOcean gave us a $500 credit, should last us a while :)

[11:44:09.0000] <foolip>
No strings attached, don't need to put a banner anywhere :)

[12:40:13.0000] <TimothyGu>
\o/

[13:43:13.0000] <Domenic>
Nice :)

[13:43:42.0000] <Domenic>
annevk: maybe Mozilla all hands is a good place to gather thoughts on/interest in observables?

[14:14:58.0000] <Domenic>
TabAtkins: have you rolled widlparser since https://github.com/plinss/widlparser/pull/33 (mixins)? If not want me to file an issue?

[14:15:08.0000] <TabAtkins>
Not yet, and please do.

[14:15:18.0000] <TabAtkins>
Been pulled 15 ways this week, sorry.

[14:20:52.0000] <Domenic>
Great. Filed https://github.com/tabatkins/bikeshed/issues/1154 for anyone else who wants to watch along.

[14:21:48.0000] <TabAtkins>
(Since the rolling method is literally "delete the folder, re-clone the wildparser repo, then delete its .gitconfig/etc files", I'll def accept a PR for it too if you want it *right now*.)

[14:22:24.0000] <TabAtkins>
(Yes, this is ridiculous, but fuck git submodules.)

[14:23:04.0000] <foolip>
There's git subtree, but that's also not great.

[14:25:13.0000] <TabAtkins>
It's all bad. Manually cloning is literally the most effective method, which is an exceedingly damning indictment of every existing solution.

[15:21:44.0000] <Domenic>
The fact that whatwg/meta has 13 watchers does not bode well for its status as a replacement for whatwg⊙wo for purposes like https://github.com/whatwg/meta/issues/58

[15:21:54.0000] <Domenic>
Probably we should tweet that thread?

[15:22:06.0000] <Domenic>
And/or send it to whatwg⊙wo?

[15:22:29.0000] <Domenic>
Also, perhaps we should send a notice of the further working mode changes blog post to whatwg⊙wo.

[15:34:54.0000] <foolip>
Heh, that would be a good place to post it, yes. It crossed my mind but then it exited my mind again.

[15:51:37.0000] <jyasskin>
I'll be at the London IETF meeting.


2017-12-14
[18:46:07.0000] <othermaciej>
does anyone here know what happens in an IETF meeting other than WG meetings?

[18:47:05.0000] <Domenic>
Seems like a good question to ask on that thread... I found https://ietf.org/tao.html#rfc.section.3

[20:00:41.0000] <annevk>
Domenic: smaug____ is not here

[20:03:11.0000] <annevk>
I support updating the mailing list with news and tweeting interesting threads

[20:03:21.0000] <annevk>
Happy to help next week

[01:12:13.0000] <tobie>
littledan: you should really split up your spec repo so you can add pr-preview to it.

[01:12:20.0000] <tobie>
littledan:

[02:36:45.0000] <foolip>
Ms2ger: the promise cleanup isn't on OKRs or anything, but Mike has only next week to work on it. Review appreciated, but I could to it too if you like.

[02:37:22.0000] <foolip>
Or at least someone who's being paid to, if it's not fun and rewarding.

[02:43:03.0000] <littledan>
tobie: Interesting idea. Seems like we'd need to do some work to integrate ecmarkup and pr-preview... another thing on my todo list I guess

[02:43:12.0000] <littledan>
I didn't know about that tool. thanks for the link

[02:44:07.0000] <tobie>
ecmarkup is a node project, right? It would be trivial to integrate as a post-processor.

[02:44:19.0000] <tobie>
littledan: happy to hook it up for you.

[02:44:40.0000] <littledan>
that'd be really helpful!

[03:25:55.0000] <Ms2ger>
foolip, how about I see what the PR ends up looking like, and I'll ping you if I won't have time?

[04:07:13.0000] <foolip>
Ms2ger: SGTM, thanks!

[05:07:02.0000] <foolip>
In https://github.com/whatwg/dom/issues/544 I don't see the string "compat". It seems unlikely to me that adding such a short and useful name on EventTarget would be web compatible, has anyone done any digging yet?

[05:07:07.0000] <foolip>
^ annevk

[05:11:19.0000] <annevk>
foolip: at this point we don't have implementer interest although othermaciej did comment with some questions, so I'm not sure it's worth bikeshedding names

[05:12:07.0000] <annevk>
foolip: that thread is already way longer than is ideal, but not unexpected due to the excited around new things 😃

[05:58:13.0000] <foolip>
annevk: ok, good

[06:18:05.0000] <annevk>
JakeA: "This also happens before unsetting the event's passive listener flag, so preventing default should be fine for spec-dispatched events" is not true

[06:18:49.0000] <annevk>
JakeA: unless you want to change all algorithms that dispatch an event and look at its canceled flag afterwards to wait for all microtasks to end first, effectively breaking compat of sorts

[06:19:16.0000] <annevk>
JakeA: as currently you can expect that by the time the microtask runs the spec-defined action has already happened

[06:19:31.0000] <JakeA>
annevk: huh, but aren't microtasks handled as part of calling the callback?

[06:20:32.0000] <annevk>
JakeA: hmm, I see, so click() and a normal mouse click would be different

[06:21:06.0000] <annevk>
JakeA: that's going to be somewhat confusing

[06:51:28.0000] <JakeA>
annevk: especially now EventTarget is constructible/extendable, we'll see more dispatchEvent usage

[06:58:01.0000] <smaug____>
Since I don't know the history behind AbortController and AbortSignal, why are they separate things?

[06:58:49.0000] <annevk>
smaug____: being able to hand someone a signal without giving away control

[06:58:53.0000] <JakeA>
smaug____: folks really wanted the ability to abort and the ability to be abortable to be separate

[06:59:04.0000] <smaug____>
Why wouldn't there be just Abortable object which inherits EventTarget (or possibly just have a getter for a promise which is resolved when aborted or something)

[06:59:24.0000] <smaug____>
Why they need to be separate?

[07:00:17.0000] <JakeA>
smaug____: eg, in a service worker, fetchEvent.request.signal will tell you if the browser wants the request to be cancelled

[07:00:34.0000] <JakeA>
this might be because some JS on the page called controller.abort(), or it might be because a tab closed

[07:01:30.0000] <smaug____>
hmm, why wouldn't request be EventTarget with onabort on it

[07:01:37.0000] <smaug____>
oh well, the ship has probably sailed

[07:02:25.0000] <JakeA>
smaug____: So you have onabort on requests & onabort on controllers?

[07:02:44.0000] <annevk>
smaug____: Request is carrying information around, it doesn't really represent an ongoing thing

[07:03:15.0000] <annevk>
smaug____: that also wouldn't really allow you to pass the signal around to other things that might need to react to it

[07:03:39.0000] <smaug____>
I would have expected request itself basically been the signal

[07:03:45.0000] <annevk>
(the ship has sailed, FWIW, but it would be good to have a shared understanding)

[07:03:58.0000] <annevk>
smaug____: so every API that takes a signal would have to take a Request?

[07:04:14.0000] <smaug____>
no

[07:04:24.0000] <smaug____>
signal could have been a mixin or so

[07:04:37.0000] <JakeA>
smaug____: https://developers.google.com/web/updates/2017/09/abortable-fetch#in_a_service_worker might help

[07:05:22.0000] <smaug____>
not really

[07:06:10.0000] <JakeA>
smaug____: is your proposal fetch(url, { signal: event.request })?

[07:07:23.0000] <JakeA>
I wanted there to be a clear distinction between "pls attempt to abort" and "this has aborted"

[07:07:47.0000] <JakeA>
With request.onabort, it wouldn't be clear which that was

[07:08:53.0000] <smaug____>
I guess I don't understand why we want the same signal in fetch(url, { signal: event.request.signal })

[07:09:04.0000] <smaug____>
looks wrong to me

[07:09:13.0000] <smaug____>
but this is serviceworkers, so I stop looking at this now

[07:12:56.0000] <annevk>
smaug____: you want the fetch (or multiple of them) in the service worker to be dependent on the main thread

[07:14:14.0000] <JakeA>
fetchEvent.request gives details on the request the browser would make if the service worker wasn't there. It includes the abort signal. You may want to make a different request, but one that's 'inspired' by the original request. Eg use some of the same headers, search string etc etc. One of the things you probably want to copy is any intent to abort.

[07:21:04.0000] <smaug____>
JakeA: so what if the original request is aborted or you end up using same signal with many fetch calls

[07:21:20.0000] <smaug____>
I think I'm missing something in this expected pattern

[07:21:58.0000] <JakeA>
smaug____: using the same signal with many fetches is fine if they're related https://developers.google.com/web/updates/2017/09/abortable-fetch#one_signal_many_fetches

[07:23:01.0000] <smaug____>
JakeA: signal says it is aborted

[07:23:17.0000] <smaug____>
but it is just one of the fetches

[07:24:15.0000] <smaug____>
I guess you're saying that if one is interested in the case when any of the fetches in a group fails, then this works fine

[07:25:36.0000] <JakeA>
smaug____: fetchStory() is an operation that may involve n fetches. Aborting that operation will involve aborting any of those active fetches, and avoiding any additional ones.

[07:28:53.0000] <smaug____>
hmm, still missing something :) I would understand this if signal (should be then called something else) was abortable, and calling abort() on it would abort all the fetch and then abort event would be dispatched. But I guess the controller is now somewhere else, hidden

[07:35:46.0000] <JakeA>
smaug____: So, I give you a buzzer, and tell you to do star jumps until the buzzer buzzes. I, the owner of the buzzer, know the special code to emit to make the buzzer buzz. The signal is the buzzer.

[07:36:08.0000] <JakeA>
You can't make the buzzer buzz. It's my buzzer.

[07:36:40.0000] <JakeA>
You're holding it, so you can react to it buzzing.

[07:37:22.0000] <smaug____>
And why we want this pattern?

[07:37:59.0000] <wanderview>
/me wonders what is going on here...

[07:38:02.0000] <smaug____>
anyhow, sounds like I should read all the relevant discussions which has lead to this

[07:38:05.0000] <wanderview>
/me reads backscroll...

[07:38:36.0000] <smaug____>
wanderview: nothing too useful. I'm not being familiar with various reasoning around service worker related API design

[07:39:02.0000] <smaug____>
definitely an area I should stay away :)

[07:39:21.0000] <JakeA>
smaug____: this isn't a service worker API

[07:39:38.0000] <JakeA>
smaug____: Other languages have similar things https://msdn.microsoft.com/en-us/library/system.threading.cancellationtoken(v=vs.110).aspx#Anchor_6

[07:40:53.0000] <wanderview>
smaug____: I think its just separation of concerns... separate interfaces for "ability react to the abort" and "ability to trigger the abort"

[07:41:19.0000] <wanderview>
smaug____: some people really wanted this and I think it made some things cleaner to integrate with fetch, streams, and service worker

[07:41:47.0000] <wanderview>
smaug____: but fetch abort was a massive bikeshed fest... honestly I accept anything JakeA/annevk/Domenic were able to get consensus on just to have the capability

[07:43:22.0000] <smaug____>
ok. And yeah, I'm not proposing any changes since the ship has sailed, as I said.  Occasionally it would be just nice to understand the reasoning.

[07:44:13.0000] <JakeA>
smaug____: it's entirely possible there's a better pattern that wasn't considered, as with everything

[07:44:16.0000] <JakeA>
do you have one in mind?

[07:45:16.0000] <smaug____>
not sure it is even worth to think about that now.

[07:45:50.0000] <smaug____>
(random note, I wish more people would have commented microtasks when they were introduced. Perhaps we would have found some better idea.)

[07:47:15.0000] <wanderview>
its also easier to combine separate interfaces into a single object (put abort() on signal) then it is to split things in the future... so it seemed safer to start with this

[07:47:25.0000] <wanderview>
maybe we can make a simplified abort interface in the future

[08:10:03.0000] <annevk>
Domenic: https://searchfox.org/mozilla-central/source/dom/html/HTMLInputElement.cpp#180 already seems like a different feature

[08:10:08.0000] <annevk>
Domenic: and it's not even behind a flag

[08:10:10.0000] <annevk>
smaug____: ^^

[08:10:35.0000] <annevk>
/me wonders if that inputmode thing impl is hooked up to something

[08:11:23.0000] <smaug____>
I thought it is used on android, but I could be wrong

[08:12:52.0000] <smaug____>
I think I'm wrong

[08:25:04.0000] <annevk>
othermaciej: was Event's having cancel() a typo? Firefox does not have that method at least

[08:25:25.0000] <othermaciej>
IT was, I meant stopPropagation(), as Jake correctly inferred

[08:26:33.0000] <othermaciej>
Just so I can avoid asking more basic questions in the issue, where in the event dispatch process is the microtask queue drained?

[08:26:43.0000] <othermaciej>
Is it after every individual event listener gets called?

[08:27:03.0000] <annevk>
othermaciej: it depends on whether the JavaScript stack is empty

[08:27:17.0000] <annevk>
othermaciej: and yes, that is the point

[08:27:46.0000] <annevk>
othermaciej: that invokes an algorithm defined in IDL that integrates with HTML that drains the microtask queue if the JavaScript stack is empty

[08:27:57.0000] <JakeA>
othermaciej: https://dom.spec.whatwg.org/#concept-event-listener-inner-invoke step 7, to https://heycam.github.io/webidl/#call-a-user-objects-operation step 16.2, to https://html.spec.whatwg.org/multipage/webappapis.html#clean-up-after-running-script

[08:28:03.0000] <othermaciej>
making the timing of event delivery depend on whether the JavaScript stack is empty seems bad

[08:28:39.0000] <annevk>
smaug____ should know why microtasks work this way

[08:28:55.0000] <annevk>
It's probably about time we start adding note around it

[08:29:02.0000] <othermaciej>
besides dispatching custom events by hand, I'm pretty sure there are Web Platform APIs that will synchronously dispatch an event from a method called from JavaScript

[08:29:27.0000] <othermaciej>
for example element.click()

[08:29:33.0000] <othermaciej>
or element.focus()

[08:29:58.0000] <othermaciej>
This seems like a big weakness of the Observable proposal, yet is required to get the nice integration with async/await

[08:31:27.0000] <JakeA>
abortController.abort() causes the "abort" event to fire on the related signal without a turn of the event loop too

[08:31:40.0000] <smaug____>
The idea with microtask behaving that way was to let event listeners work without necessarily affecting each others. So that when a listener is called, all the mutation observer callbacks would have been called already.

[08:32:08.0000] <smaug____>
Note, Microtasks were designed way before all the Promise stuf

[08:32:36.0000] <JakeA>
That behaviour enables IDB to be wrapped in promises, so I'm a fan

[08:32:47.0000] <smaug____>
or perhaps there were ideas of Promises or Futures, but their scheduling definitely wasn't based on microtasks initially

[08:32:57.0000] <othermaciej>
I am definitely not questioning the timing of microtasks

[08:33:05.0000] <othermaciej>
I just wanted to understand what it is

[08:33:22.0000] <othermaciej>
Since this Observable proposal for events depends on it

[08:33:45.0000] <smaug____>
(I have started to question the timing of microtasks because devs seem to misuse them badly by creating long promise chains, and that causes jank)

[08:34:52.0000] <smaug____>
(but as I said, microtasks were not designed with Promise kind of thing in mind. )

[08:35:09.0000] <JakeA>
(I only mention the IDB thing because that's when I 'discovered' that microtasks happen between event callbacks in stack-empty cases)

[09:51:28.0000] <Domenic>
MikeSmith: I don't see any changes at https://github.com/validator/validator/commits/master, but the validator in the CI build for HTML started reporting the focus-within etc. CSS errors again. Any chance you pushed some changes to the .tgz or something that might have regressed?

[09:53:41.0000] <MikeSmith>
hmm could be

[09:53:44.0000] <MikeSmith>
/me looks

[10:24:08.0000] <MikeSmith>
Domenic: fixed

[10:24:11.0000] <MikeSmith>
sorry about that

[10:24:19.0000] <Domenic>
Phew. What happened?

[10:24:25.0000] <MikeSmith>
the formatting of the messages changed

[10:24:49.0000] <MikeSmith>
I added “ and ” around the literals in the messages

[10:25:05.0000] <MikeSmith>
> Unknown pseudo-element or pseudo-class “:focus-within”

[10:25:23.0000] <MikeSmith>
> “leader(". ")” is not a “content” value

[10:25:32.0000] <MikeSmith>
those were unquoted before

[10:25:53.0000] <MikeSmith>
the filter expression didn’t account for the quotes

[10:26:25.0000] <MikeSmith>
I’ll add some tests

[10:26:40.0000] <MikeSmith>
so that I don’t regress it again

[10:26:58.0000] <Domenic>
\o/

[14:10:35.0000] <annevk>
jgraham: https://github.com/whatwg/meta/issues/58

[14:19:15.0000] <jgraham>
annevk: Thanks

[14:29:05.0000] <muteki>
someone explained to me CORS as follow: "Lets make it easier. badsite.com sends a JS asset to your browser and in that JS it tells your browser to request bank.com/send-money-to-the-bad-guys, bank.com is the one who sets the headers that allow requests to come from badsite.com"

[14:29:16.0000] <muteki>
but is it true if badsite is not aware by bank.com, the request send-money-to-the-bad-guys still be issued by the browser and processed by bank.com, it's just the response not being processed by the browser?

[14:40:06.0000] <TimothyGu>
muteki: how does badsite.com send a JS asset in the first place?

[14:42:01.0000] <muteki>
good question, I didn't ask, but I guess probably the user wander to that page accidentally?

[14:42:24.0000] <muteki>
I was basically asking some general concepts behind CORS and that's the response I got

[14:57:04.0000] <annevk>
muteki: did you read through the examples in the Fetch Standard?

[14:58:16.0000] <muteki>
annevk: you meant 3.2.6 in https://fetch.spec.whatwg.org/#cors-protocol ?

[15:00:07.0000] <muteki>
I think I understand how it works, but I am just trying to understand the rationale behind it and what does it use to protect against... especially the example mentioned by others about bank.com, seems to be not quite fitting the actual CORS protocol

[15:00:45.0000] <annevk>
muteki: I have to admit I don’t quite follow that example either

[15:01:01.0000] <muteki>
wondering maybe that example (badsite.com/bank.com) is not quite accurate

[15:01:39.0000] <annevk>
muteki: CORS in principle does not protect; it enables sharing of otherwise protected resources

[15:02:35.0000] <annevk>
muteki: the reason those resources are protected is because they might contain confidential information about the user or the user’s local network

[15:02:53.0000] <muteki>
annevk: I think that makes sense, because the resource can be accessed regardless using curl or other method, but it's to workaround (or provide way to add exception) to the same origin policy enforced by the browser, am I correct?

[15:03:38.0000] <annevk>
muteki: you cannot always fetch it with curl

[15:03:54.0000] <annevk>
muteki: consider a fetch with the cookies from the user

[15:04:17.0000] <annevk>
muteki: or to a local IP or IP-authenticated server

[15:04:32.0000] <annevk>
muteki: https://annevankesteren.nl/2015/02/same-origin-policy might also help

[15:04:53.0000] <muteki>
thanks, let me read through that

[15:40:57.0000] <muteki>
annevk: thanks for the link, so here is what I gathered after reading your blog plus the example people gave me, please let me know if I am missing anything...  it sounds like his badsite.com is untrusted.example as described in your blog and bank.com is intranet.example.  so, without CORS, bad JS hosting by untrusted.example can ask user's browser to access resource on intranet.example.  but even with

[15:41:03.0000] <muteki>
CORS, untrusted.example can still serve bad JS to browser, and browser will send request to intranet.example and response will be sent but not process by browser..  and if we want to prevent request (or full power request in your blog) processed by intranet, we need preflight requests for further protection.  am I correct?


2017-12-15
[16:28:08.0000] <MikeSmith>
muteki: without CORS, no site can make any cross-origin XHR/Fetch request from JavaScript to another site, period

[16:29:13.0000] <MikeSmith>
browsers by default block all scripted cross-origin requests

[16:30:00.0000] <MikeSmith>
CORS allows sites to opt-in to telling browsers that they are OK with receiving cross-origin requests

[16:30:51.0000] <MikeSmith>
actually “browsers by default block all scripted cross-origin requests” is not quite correct

[16:31:40.0000] <MikeSmith>
more accurately, browsers block frontend JavaScript code from accessing the response to any cross-origin request

[16:33:08.0000] <MikeSmith>
so you can make a cross-origin GET request to another site, but unless the site sends back teh Access-Control-Allow-Origin response header, your browser blocks your JavaScript code from accessing the response

[16:44:47.0000] <muteki>
MikeSmith: my bad, I was reading annevk's blog so what I meant is really without SOP, then CORS comes in and with CORS...

[16:45:01.0000] <MikeSmith>
yeah

[16:46:24.0000] <MikeSmith>
muteki: you might find https://w3c.github.io/webappsec-cors-for-developers/ worth reading

[16:46:59.0000] <muteki>
MikeSmith: yeah, I think your differentiation of allowing javascript to process the code v.s. issuing request+getting response are two separate things that I was confused initially

[16:47:14.0000] <MikeSmith>
yeah that is non-intuitive really

[16:47:39.0000] <MikeSmith>
I mean, by default you can even successfully make POST requests cross-origin

[16:48:25.0000] <muteki>
yeah, there is nothing really to protect that unless one leverages the preflight requirement

[16:48:36.0000] <MikeSmith>
right, as long as your request doesn’t add any headers or set to the Content-Type header to application/json or something, then any POST request will succeed cross-origin

[16:49:46.0000] <MikeSmith>
anyway I guess the https://w3c.github.io/webappsec-cors-for-developers/#csrf section in particular is where the problem case is explained

[16:49:59.0000] <muteki>
ok, thanks, let me read about it

[16:51:14.0000] <MikeSmith>
the last paragraph of https://stackoverflow.com/questions/34650915/it-seems-the-pre-flight-for-cors-doesnt-make-sense-is-it-a-joke/34668785#34668785 from Domenic is also a very good succinct explanation

[16:52:06.0000] <MikeSmith>
and https://stackoverflow.com/questions/9222822/why-do-browser-apis-restrict-cross-domain-requests/9223680#9223680 is very good too

[16:59:49.0000] <muteki>
thanks so much, I think I have a better idea what CORS really provide and the rationale behind using it

[17:10:39.0000] <muteki>
I that last link also implies why normal cross-origin img request via <img> tag is ok but canvas img loading is not ok....  (have been wondering that for a while) (because canvas can read back the img and potentially send it back to the bad site)

[17:15:15.0000] <muteki>
correction: canvas image loading is ok, but once tainted, can't pull data out

[17:56:34.0000] <MikeSmith>
Domenic: about the checker problem that broke the HTML spec build, in https://github.com/w3c/web-platform-tests/commit/bf24230 I added a test to make sure it doesn’t regress

[23:25:04.0000] <MikeSmith>
annevk: any clue about https://stackoverflow.com/questions/47158940/include-authorization-header-using-fetch-api-post-method

[01:14:14.0000] <kochi>
Hmm, Ryosuke suggested somewhere else than Toronto, any idea if we do elsewhere?

[01:23:27.0000] <smaug____>
kochi: where was that discussed?

[01:23:52.0000] <kochi>
smaug____: https://github.com/w3c/webcomponents/issues/713

[01:24:15.0000] <smaug____>
hmm, I'm so not getting emails about that issue

[01:24:29.0000] <smaug____>
even though I'm subscribed :/

[01:24:36.0000] <kochi>
smaug____: I thought you preferred somewhere in Europe

[01:24:38.0000] <smaug____>
oh, now I got it

[01:25:13.0000] <kochi>
strange, I explicitly mentioned @smaug---- in my comment.

[01:28:19.0000] <smaug____>
(there are direct flights from Helsinki to Tokyo, so it wouldn't be too hard for me)

[01:31:05.0000] <smaug____>
Though, Google does have offices in London. Any blink folks there?

[01:31:56.0000] <Ms2ger>
I think so

[01:33:06.0000] <smaug____>
-> out

[01:37:07.0000] <kochi>
yes, Google has London office, and has Chrome people there.

[01:37:35.0000] <kochi>
London wouldn't be hard for me.

[01:37:43.0000] <kochi>
But I've never been there ;)

[01:43:46.0000] <JakeA>
smaug____: beverloo and I work at Google in London

[01:44:16.0000] <JakeA>
(although I don't work on blink)

[01:45:45.0000] <kochi>
So now Berlin (Mozilla), London (Google), Tokyo (Google), Toronto (Mozilla) are the options.

[01:46:27.0000] <kochi>
How the weather in Berlin in February/March?

[01:47:16.0000] <JakeA>
Dan Abramov of React is in London too

[01:51:02.0000] <kochi>
Is London not as bad as Toronto in Feb/Mar?

[01:55:59.0000] <JakeA>
Winters in southern UK aren't particularly serious. We very rarely get snow.

[02:02:47.0000] <kochi>
Then it's like Tokyo, or better maybe. We have snow once or twice a year.

[03:58:12.0000] <gsnedders>
is there any way to make Fetch compress the request body?

[04:39:11.0000] <zcorpan>
rbyers: any update on https://bugs.webkit.org/show_bug.cgi?id=5991#c17 ? :-)

[04:39:11.0000] <smaug____>
/me doesn't understand what is wrong with snow ;)

[04:39:12.0000] <jgraham>
Not very relevant but you could also use the Mozilla London office for a SW meeting if you wanted.

[04:39:51.0000] <nox>
There is Paris too. :P

[04:39:52.0000] <smaug____>
jgraham: this is webcomponents, and thought there might be a bit too many people possibly coming

[04:42:41.0000] <jgraham>
smaug____: Ah. Well yeah I guess more than ~20 would be hard

[04:43:08.0000] <smaug____>
Maybe there won't be too many, but it is unclear still

[04:43:09.0000] <jgraham>
Google is probably a better bet in London, just making sure you have options :)

[04:44:03.0000] <smaug____>
Does Google still have the office on the Buckingham Palace's backyard?

[04:45:23.0000] <smaug____>
looks like so

[04:51:30.0000] <foolip>
annevk: is html5.org yours? is it really based on https://github.com/whatwg/misc-server/tree/master/html5.org?

[04:52:31.0000] <annevk>
foolip: it's not automatically deployed, but I try to keep those directories synchronized

[04:52:47.0000] <foolip>
annevk: OK, was thinking about deleting that, but I won't then

[04:53:02.0000] <foolip>
(In the context of maybe merging misc-server into whatwg.org/config/

[04:53:24.0000] <foolip>
They're kind of interdependent now...

[04:53:51.0000] <annevk>
You could just leave this in misc-server for now I suppose

[04:54:06.0000] <foolip>
Just html5.org? That'd work, yeah.

[04:54:15.0000] <annevk>
I'm also happy to move it elsewhere, but not this week

[04:54:23.0000] <foolip>
Nope, doesn't really matter.

[08:06:25.0000] <JakeA>
wanderview: When did e10s become the default in Firefox?

[08:06:43.0000] <wanderview>
JakeA: single content process or multiple content processes?

[08:07:03.0000] <wanderview>
JakeA: its actually a hard question to answer because it was a gradual rollout with all kinds of exceptions

[08:07:27.0000] <wanderview>
JakeA: 57 may be the real first release where 100% users have e10s on desktop because legacy addons blocked e10s for many users

[08:07:41.0000] <JakeA>
wanderview: I guess I'm asking, when did JS in one tab stop blocking JS in an unrelated tab?

[08:08:54.0000] <wanderview>
JakeA: we enabled 4 content processes in FF54, but many users may not have seen that because of addons, etc: https://medium.com/mozilla-tech/the-search-for-the-goldilocks-browser-and-why-firefox-may-be-just-right-for-you-1f520506aa35

[08:09:13.0000] <wanderview>
JakeA: pages that get put in the same process can still block each other

[08:09:55.0000] <JakeA>
wanderview: gotcha, cheers!

[08:10:33.0000] <wanderview>
JakeA: we have "quantum DOM" plans to fix that within a process, but its not ready yet

[08:11:45.0000] <JakeA>
wanderview: so does Firefox now create a new process per event loop?

[08:12:16.0000] <wanderview>
JakeA: no... we create up to four processes and assign tabs to them somewhat randomly

[08:12:29.0000] <JakeA>
wanderview: ahh ok, gotcha, thanks!

[08:18:15.0000] <wanderview>
JakeA: not sure if it matters or not, but we have a thing in "Menu->Options search for perf" that lets you choose up to 7 processes or as few as 2 processes

[08:18:36.0000] <wanderview>
oh, it goes down to1 now

[10:12:49.0000] <Domenic>
foolip: several times over the last couple of days I've browsed through wpt.fyi and found failing-in-all-four-browsers tests that seem pretty clearly incorrect. I guess I'll file bugs, but are you perhaps working on a larger project to canvas those?

[10:14:47.0000] <foolip>
Domenic: we're not planning a repo-wide effort like that, but it is the obvious place to start if trying to improve the test suite itself as opposed to implementations

[10:14:57.0000] <Domenic>
Hmm OK

[10:16:10.0000] <foolip>
Domenic: as a start, https://metrics5-dot-wptdashboard.appspot.com/metrics/ will make it easy to find them

[10:16:22.0000] <Domenic>
Ah nice

[10:17:13.0000] <foolip>
That'll become the default view (after some polish)

[10:23:25.0000] <Domenic>
Hmm I guess the reliability of the data really hurts this

[10:23:29.0000] <Domenic>
E.g. Firefox randomly missing results

[10:24:01.0000] <Domenic>
Or maybe it's just too beta

[10:24:16.0000] <Domenic>
E.g. https://metrics5-dot-wptdashboard.appspot.com/metrics/dom/nodes/prepend-on-Document.html says there are 7 tests one of which passes nowhere, but there are 5 tests and they all pass in at least Firefox.

[14:51:30.0000] <foolip>
Domenic: run cadance and completeness of results is a P1 for us, it'll get good.

[14:51:54.0000] <foolip>
Domenic: oh, but that might be a bug

[15:58:13.0000] <foolip>
Domenic: I told mditty (hi!) and there are actually 7 rows there

[15:59:17.0000] <mditty>
Domenic: The metrics view is showing all 7 rows listed at https://metrics5-dot-wptdashboard.appspot.com/dom/nodes/prepend-on-Document.html

[15:59:51.0000] <foolip>
Confusing bit is that testharness.js tests all get an extra line for the harness status, and that not the same commit of wpt was run on all browsers, so the last line is Edge only

[15:59:53.0000] <mditty>
It looks like Edge is the only one with a subtest named "DocumentType.prepend"


2017-12-16
[16:00:32.0000] <foolip>
Oh look, the Safari run is updated

[16:00:39.0000] <mditty>
The metrics search controller takes the union of all known sub-tests (which is a pretty inconsistent worldview, considering we don't have wpt repo hash-aligned test runs across all browsers right now)

[16:01:57.0000] <foolip>
Yep, but union will make sense in the end, as the same tests might not be run everywhere. Usually a bad test, but not always.

[16:02:10.0000] <foolip>
/me sleeps

[16:03:06.0000] <Domenic>
Hmm that page is blank for me

[16:03:47.0000] <Domenic>
Anyway, Star Wars time now :)

[06:18:25.0000] <Carl_>
hey there

[06:21:16.0000] <Carl_>
is there any big differency between you and the w3c?

[06:22:59.0000] <Carl_>
i mean despite the fact that you both cannot create up to date web-designs?

[06:23:05.0000] <foolip>
Carl_: there are many differences, but the most interesting thing is probably what specs we work on

[06:23:26.0000] <Carl_>
okay

[06:23:42.0000] <foolip>
Carl_: that's right, we haven't tried very hard to make things pretty

[06:24:07.0000] <Carl_>
why? :(

[06:26:18.0000] <annevk>
Hmm, for the components F2F we have to pick between rniwa, Domenic, and Tom Dale :/

[06:26:58.0000] <annevk>
Carl_: it's not easy, mostly

[06:27:27.0000] <annevk>
Carl_: see https://github.com/whatwg/whatwg.org/issues/59 and https://github.com/whatwg/whatwg.org/pull/90 for some ideas

[06:27:52.0000] <Carl_>
thanks :)

[06:28:54.0000] <Carl_>
wait

[06:28:59.0000] <Carl_>
not mobile friendly?

[06:29:15.0000] <Carl_>
really? -.-

[06:33:15.0000] <annevk>
Well as I mentioned there, it works, but it could be better

[08:28:20.0000] <domfarolino>
annevk: what is the no-backref class used for?

[09:08:17.0000] <annevk>
domfarolino: do you know that you can click on a definition and find all the places that refer to it?

[09:08:23.0000] <annevk>
domfarolino: this excludes it from that list

[09:39:07.0000] <domfarolino>
annevk: oh ok thanks


2017-12-17
[02:20:47.0000] <smaug____>
/me wonders which js frameworks use or would like to use web components

[02:22:02.0000] <smaug____>
if React and such don't really need it, and React-style frameworks dominate, what are the needs to add new features to web components

[03:46:45.0000] <AllCapo378>
▄▄▄▄▄▄▄▄▄▄▄▄▄▄ HAPPY NIGGER DAY!! PLEASE SAY HI TO ALL THE DUMB NIGGERS IN #OFTC...quicktalkeh676te.onion/6697oxycrc: KiChjang robertkowalski dveditz_ AutomatedTester jrabe ^esc mmn not-an-aardvark zewt TimothyGu sarri annevk beverloo musgravejw ricea paul_irish webguynow rbyers danyao Manishearth farre Yudai floatleft umpc mkohler treora felixsanz espadrine le

[03:46:45.0000] <AllCapo378>
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ HAPPY NIGGER DAY!! PLEASE SAY HI TO ALL THE DUMB NIGGERS IN #OFTC...quicktalkeh676te.onion/6697gzbawo: sangwhan antoligy_ ShekharReddy schuki fivre musgravejw mmn ricea hayato leviw_ umpc Yudai muteki webguynow felixsanz astearns XhmikosR Zegnat fujihiro shawnjohnjr_____ espadrine kbrosn

[03:46:45.0000] <AllCapo378>
▄▄▄▄▄▄▄▄▄▄▄▄▄ HAPPY NIGGER DAY!! PLEASE SAY HI TO ALL THE DUMB NIGGERS IN #OFTC...quicktalkeh676te.onion/6697ltiaqvmm: nunnun justJanne timeless mkohler astearns haptiK zewt jrabe felixsanz timdream kbrosnan beverloo paul_irish jihye mven sivoais phedenskog fivre dveditz_ Yudai jungkees mmn leviw_ espadrine shawnjohnjr_____ so webguynow gnarf timwis edsu mcasas annevk h

[03:47:24.0000] <KiChjang>
huh, it's not that often we see trolls in here

[03:57:48.0000] <Zegnat>
KiChjang, this i doing the rounds, it seems. I had one of these messages directed messaged to me earlier too. You might want to set mode +R on yourself if you haven’t already

[08:03:59.0000] <domfarolino>
Why does the HTML navigation algorithm use a request whose redirect mode is manual? I'm guessing Domenic or annevk might know. Context: https://stackoverflow.com/a/42717388/3947332

[08:04:54.0000] <annevk>
domfarolino: to handle redirects to non-HTTP schemes

[08:05:15.0000] <domfarolino>
ahhhh lovely


2017-12-18
[02:26:38.0000] <zcorpan>
@media (scripting) {

[02:26:38.0000] <zcorpan>
  noscript { display: none !important; }

[02:26:39.0000] <zcorpan>
}

[02:26:43.0000] <zcorpan>
https://html.spec.whatwg.org/#hidden-elements

[02:26:57.0000] <zcorpan>
Where is "scripting" defined? Can't see it in https://drafts.csswg.org/mediaqueries/

[02:42:12.0000] <annevk>
It seems the CSS WG might have dropped it without notifying dependencies...

[02:42:37.0000] <annevk>
zcorpan: https://drafts.csswg.org/mediaqueries-5/#mf-scripting

[02:43:06.0000] <zcorpan>
annevk: thanks

[02:45:20.0000] <annevk>
Seems that was done in https://github.com/w3c/csswg-drafts/commit/8677d3ea21533f151143784846992f2cdcdf07ae#diff-86306790afb9d5330bbdda192a7b99f6

[02:45:35.0000] <annevk>
But latest version still referencing -4 is what makes this so confusing

[04:23:16.0000] <annevk>
hsivonen: if you're around, could you look at https://github.com/whatwg/html/pull/3111?

[04:29:27.0000] <hsivonen>
annevk: looking

[04:33:48.0000] <annevk>
hsivonen: it basically seems like another all encodings decoding path in the platform, but one that might not use the BOM at all

[04:34:18.0000] <annevk>
hsivonen: I'm hoping we can restrict it to UTF-8 given that the URL parser already always uses UTF-8 to encode, but who knows

[04:38:12.0000] <hsivonen>
annevk: It's likely that I didn't understand the question in the issue

[04:39:21.0000] <annevk>
hsivonen: part of the problem here is that if an ID contains U+00FF and the document encoding is windows-1252, a %FF fragument will find that ID in most implementations

[04:39:44.0000] <annevk>
hsivonen: meaning that the fragment is not UTF-8 decoded, but decoded using the document encoding

[04:40:21.0000] <annevk>
hsivonen: furthermore, if the fragment starts with an encoded BOM, that's ignored for decoding purposes (so it doesn't use the generic decode hook)

[04:40:49.0000] <hsivonen>
annevk: when you say "ignored", is it removed or retained if the document encoding is UTF-8?

[04:41:16.0000] <annevk>
hsivonen: retained

[04:42:03.0000] <hsivonen>
annevk: encoding_rs has https://docs.rs/encoding_rs/0.7.1/encoding_rs/struct.Encoding.html#method.decode_without_bom_handling and https://docs.rs/encoding_rs/0.7.1/encoding_rs/struct.Encoding.html#method.decode_without_bom_handling_and_without_replacement , so it seems that no new encoding_rs API surface would be needed

[04:42:21.0000] <annevk>
hsivonen: I meant ignored in that it doesn't override the document encoding

[04:42:36.0000] <hsivonen>
also https://docs.rs/encoding_rs/0.7.1/encoding_rs/struct.Encoding.html#method.new_decoder_without_bom_handling

[04:42:39.0000] <hsivonen>
annevk: ok.

[04:43:25.0000] <annevk>
hsivonen: it seems like I was right to worry about the encoding_rs <> Encoding Standard hook mismatch

[04:44:28.0000] <hsivonen>
annevk: in what sense?

[04:45:14.0000] <annevk>
hsivonen: if we want to do what implementations do here the Encoding Standard needs a new hook

[04:47:03.0000] <hsivonen>
annevk: yeah. I suggest calling it "decode without BOM handling" :-)

[04:48:33.0000] <annevk>
hsivonen: seems unfortunate though to have that just for this one caller

[04:59:31.0000] <hsivonen>
annevk: only if you consider "UTF-8 decode without BOM" a separate thing as opposed to considering it this new thing performed with UTF-8 as the encoding

[05:00:23.0000] <annevk>
hsivonen: I consider it separate as UTF-8 decode without BOM is not a legacy code path

[05:01:07.0000] <hsivonen>
ok. probably worthwhile re-defining "UTF-8 decode without BOM" in terms of "decode without BOM handling" if you end up introducing the latter

[05:04:53.0000] <annevk>
hsivonen: is it easy to find other callers of "decode without BOM handling" that might use it for an encoding other than UTF-8?

[05:05:00.0000] <annevk>
hsivonen: or is this indeed the only place?

[05:05:16.0000] <annevk>
I wonder how much effort I should put into trying to get rid of this

[05:10:19.0000] <hsivonen>
let's see. most of these are non-Web-exposed internal legacy

[05:10:25.0000] <hsivonen>
https://searchfox.org/mozilla-central/search?q=symbol:_ZNK7mozilla8Encoding24DecodeWithoutBOMHandlingERK12nsTSubstringIcERS2_&redirect=false

[05:10:30.0000] <hsivonen>
https://searchfox.org/mozilla-central/search?q=symbol:_ZNK7mozilla8Encoding28NewDecoderWithoutBOMHandlingEv&redirect=false

[05:10:35.0000] <hsivonen>
https://searchfox.org/mozilla-central/search?q=symbol:_ZNK7mozilla8Encoding24DecodeWithoutBOMHandlingENS_4SpanIKhLm18446744073709551615EEER12nsTSubstringIDsE&redirect=false

[05:14:37.0000] <hsivonen>
annevk: looks like URL fragments are the only Web-exposed non-UTF-8 case

[05:15:31.0000] <hsivonen>
the script loader stuff uses this primitive internally but performs BOM handling, so the Web-exposed behavior is with BOM handling

[06:04:04.0000] <annevk>
hsivonen: thanks, I guess I'll make an effort to make it either use "UTF-8 decode without BOM" or "decode" (and handle the BOM) in that case

[06:15:54.0000] <Ms2ger>
Is there an easy way to test iOS Safari?

[06:24:11.0000] <annevk>
Ms2ger: BrowserStack?

[06:43:36.0000] <gsnedders>
Ms2ger: buy an iPod Touch on expenses?

[06:44:09.0000] <gsnedders>
(I have literally done that before. But I was needing to test touch behaviour, which is hard with the simulator locally yet alone remotely)

[06:44:48.0000] <Ms2ger>
Would be a good idea if I had any other use for apple devices :)

[06:45:04.0000] <gsnedders>
Oh, mine just sits in a drawer almost all of the time. :)

[06:45:26.0000] <Ms2ger>
Sounds a little wasteful

[06:45:44.0000] <Ms2ger>
I should figure out if we have a corporate browserstack account

[06:46:03.0000] <gsnedders>
Well you can't exactly do much with a 16GB iPod Touch

[06:46:15.0000] <gsnedders>
given the OS takes up some ridiculous percentage of that

[06:46:21.0000] <gsnedders>
/me wonders if they still make the 16GB model

[07:57:26.0000] <annevk>
foolip: does https://travis-ci.org/whatwg/fetch/builds/318150547 look familiar?

[07:57:34.0000] <annevk>
foolip: seems something is wrong with the build script

[07:59:42.0000] <annevk>
foolip: think I found the mistake

[08:05:10.0000] <annevk>
foolip: https://github.com/whatwg/whatwg.org/pull/135#issuecomment-352470978

[08:46:14.0000] <Shreya>
Hello everyone! I would like to be a part of whatwg.

[08:46:19.0000] <foolip>
annevk: restarted https://travis-ci.org/whatwg/fetch/builds/318150547 after (maybe) fixing

[08:47:10.0000] <Shreya>
How can I become a member of this?

[08:53:05.0000] <annevk>
Shreya: welcome, does https://whatwg.org/faq help?

[08:53:13.0000] <annevk>
foolip: ta

[08:59:24.0000] <annevk>
foolip: did not work

[08:59:42.0000] <annevk>
foolip: Travis tries rsync apparently

[09:00:05.0000] <Shreya>
Thanks annevk!

[09:02:24.0000] <annevk>
foolip: at least Fetch is still online…

[09:02:27.0000] <foolip>
foolip: maybe it hadn't deployed to resources yet, try again?

[09:03:11.0000] <annevk>
I can try in an hour or so

[09:04:04.0000] <annevk>
foolip: however seems like a different error; failing at a later step

[09:05:07.0000] <foolip>
annevk: okay, different error is interesting. Poke me when it doesn't resolve itself in a bit.

[09:05:41.0000] <annevk>
foolip: pretty sure the rsync block has the wrong guard

[09:06:02.0000] <annevk>
foolip: will poke when back

[09:06:39.0000] <foolip>
annevk: it tried to deploy for a PR then?

[09:06:48.0000] <foolip>
That would be very wrong

[09:15:44.0000] <annevk>
foolip: log suggests as much

[09:17:32.0000] <foolip>
annevk: oh now I see, it's missing the master branch check :(

[09:20:52.0000] <foolip>
annevk: https://github.com/whatwg/whatwg.org/pull/140

[09:39:28.0000] <SimonSapin>
https://blog.whatwg.org/copyright-license-change talks about the license of the HTML Standard but I couldn’t find from https://html.spec.whatwg.org/multipage/ or https://github.com/whatwg/html what it is currently or what it was before

[09:40:48.0000] <Domenic>
License changes haven't quite rolled out yet; I guess that's pretty confusing. Was planning to do it this week.

[09:41:11.0000] <Domenic>
Current license is the bottom of https://html.spec.whatwg.org/multipage/acknowledgements.html#acknowledgments

[09:43:03.0000] <SimonSapin>
thanks

[09:46:24.0000] <ato>
tobie: I just learned about pr-preview. That is fantastic.

[09:58:21.0000] <tobie>
ato: glad you like it!

[10:09:24.0000] <domfarolino>
annevk: regarding my fetch PR, what do you think should be done about referencing the request object's members vs the concept members?

[10:11:29.0000] <annevk>
domfarolino: it seems somewhat reasonable to reference the concepts since we end up returning those, but I'm not sure how understandable that is

[10:11:43.0000] <ato>
tobie: Deploying it on the WebDriver spec now.

[10:13:51.0000] <domfarolino>
Agreed, I mean the current way still sort of references the concepts, just by going through the object members first so there's one more layer of indirection, but I'm open to either

[10:14:51.0000] <annevk>
domfarolino: up to you

[10:19:06.0000] <domfarolino>
annevk: "Event" in the DOM spec doesn't seem to suffer the same duplication between the concept members and object members. Is this because events are designed to be always exposed to/created by JavaScript, so the internal properties and exposed properties are more 1:1?

[10:19:21.0000] <Domenic>
Heh, big question

[10:19:24.0000] <Domenic>
It's partially legacy

[10:19:37.0000] <Domenic>
i.e. it's pretty bad right now that specs say "initialize the foo member of the event to bar"

[10:19:40.0000] <Domenic>
because that isn't defined anywhere

[10:19:50.0000] <Domenic>
It should be saying "initialize the event's foo [concept] to bar"

[10:19:55.0000] <Domenic>
But...

[10:20:06.0000] <Domenic>
Events are a bit special because there's a precise 1:1 correspondence

[10:20:29.0000] <Domenic>
So it'd be kind of annoying to just create a bunch of concepts (aka internal slots) for this purpose

[10:21:06.0000] <Domenic>
annevk likes the solution proposed in https://github.com/heycam/webidl/pull/495 of having internal slots be generated for all Web IDL attributes (JS properties)

[10:21:17.0000] <Domenic>
I am not a big fan, as I feel like Events are the only case where that's a clear win

[10:23:18.0000] <annevk>
Domenic: it's a win whenever the getter just returns the internal slot

[10:23:34.0000] <annevk>
Domenic: as you won't have to define the getter

[10:23:39.0000] <Domenic>
Well... but only for classes where *every* getter has a backing internal slot

[10:23:47.0000] <Domenic>
Otherwise, you have to add a bunch of annotations to say "but not this one"

[10:24:15.0000] <domfarolino>
Domenic: Yes that makes sense, with the 1:1 and all.

[10:24:16.0000] <annevk>
I think that's the common case

[10:24:23.0000] <Domenic>
My impression is the opposite

[10:24:25.0000] <domfarolino>
Reading PR link thanks a lot for sending!

[10:24:32.0000] <Domenic>
But this is an empirical question

[10:25:23.0000] <domfarolino>
Ok that's an interesting solution

[10:25:50.0000] <annevk>
Need something for events though

[10:26:19.0000] <Domenic>
Yeah, agreed on that front.

[10:26:49.0000] <domfarolino>
Because of Event's missing internal slots?

[10:26:51.0000] <Domenic>
That PR isn't great for events though as it still requires listing all the internal slots (either in syntax or elsewhere)

[10:27:03.0000] <Domenic>
You really want something, maybe in DOM, that says "all events have a corresponding internal slot"

[10:27:15.0000] <domfarolino>
That sounds nice

[10:27:25.0000] <annevk>
Well slot per getter

[10:27:57.0000] <annevk>
That PR could get there

[10:28:21.0000] <annevk>
But maybe getter slots should be opt-in then

[10:29:13.0000] <annevk>
For DOM, Fetch, XHR most getters need a slot though

[10:29:32.0000] <annevk>
I wonder where that stops being true

[10:31:16.0000] <Domenic>
"most" might be true, but if it's like 80% need slots, the 20% remaining is pretty awkward, I think.

[10:33:36.0000] <annevk>
Domenic: so we add [Slot] instead?

[10:34:11.0000] <Domenic>
Hmm maybe, that does feel better for some reason

[10:34:23.0000] <annevk>
It makes some sense to not encourage slots and requiring a little hassle

[10:34:55.0000] <annevk>
It makes less sense imo to require prose for the object layout

[10:40:33.0000] <annevk>
domfarolino: sorry for the long sidebar, the basic answer is that Event (and anything like it) is wrong as-is

[10:41:02.0000] <domfarolino>
With this potential [slot] syntax, where would you describe the behavior of a slot that is specific to its non-javascript usage? Like if an internal slot has a set of possible behaviors/values, but only a subset of those are used in/available to JavaScript where would you describe its "only-internal" usage.

[10:41:29.0000] <domfarolino>
Hm if that doesn't make sense I can reword

[10:42:08.0000] <annevk>
domfarolino: you manipulate slots as you see fit from various algorithms

[10:42:33.0000] <annevk>
domfarolino: what you expose through public JavaScript API is up to you, the getter might not reflect the internal value 1:1

[10:43:25.0000] <Domenic>
It would reflect it 1:1 though for events

[10:43:33.0000] <Domenic>
And presumbly other cases where you use [Slot]

[10:50:53.0000] <domfarolino>
Yeah, I feel that using [Slot] on a getter that doesn't reflect internal value 1:1 might be a little confusing maybe

[10:52:29.0000] <domfarolino>
annevk: Ok I'm cool with the domintro boxes pointing to the object members then, because they themselves point to the concepts. I feel that that includes everything well even tho might be a little indirect

[10:52:42.0000] <domfarolino>
But I could be swayed either way

[10:54:45.0000] <annevk>
domfarolino: ok

[11:01:10.0000] <jyasskin>
Domenic/annevk: How important is it to make sure that the generic IDL language doesn't create unused slots? I'm thinking that the 20% remaining could just not use their slots, and implementations wouldn't need to allocate space for them.

[11:01:41.0000] <Domenic>
I think it'd be confusing. Not fatal, but definitely confusing.

[11:38:02.0000] <tobie>
Domenic, annevk, jyasskin, domfarolino: just to clarify, the current [slot] proposal "allocates" a slot per attribute, defaults getters and setters to read and write from slots unless their behavior is specified in prose, and allows adding custom slots on top of those.

[11:41:02.0000] <tobie>
jyasskin: it doesn't really bother me that slots get "allocated' and then not used. They're spec'ing devices anyway, not accessible in ES at all.

[11:42:31.0000] <jyasskin>
tobie: That seems totally reasonable to me. It loses a tiny bit of redundancy with which we might be able to notice spec bugs, but we have that redundancy today and so many violations of it in otherwise-correct specs, that I'd rather have your proposal.

[11:44:16.0000] <tobie>
jyasskin: that said, that PR is an initial proposal for discussion.

[11:46:05.0000] <tobie>
jyasskin: It's based on my understanding of folks need/have asked for.

[11:46:22.0000] <tobie>
jyasskin: of *what

[11:50:08.0000] <tobie>
jyasskin: Note another option would be doing this in reverse, they way Ruby does it. That is, specify all the slots you need, and have a way to create attribute getters/setters that just reflect those (see: https://stackoverflow.com/a/5046915/6197646)

[11:53:01.0000] <tobie>
jyasskin: possibly even with an extended attribute, e.g.: [reflects=foo] attribute DOMString bar;

[12:04:53.0000] <domfarolino>
tobie: FWIW I like the reverse way a lot, since the internal slots will always exist and we can cherry pick which ones will be exposed to ES

[12:05:21.0000] <tobie>
domfarolino: the one I just described above?

[12:05:48.0000] <domfarolino>
tobie: yep, the Ruby way. I kind of like it

[12:06:38.0000] <Domenic>
I too find it fairly nice.

[12:07:50.0000] <tobie>
oh, would we be moving towards consensus?

[12:08:23.0000] <tobie>
TabAtkins, annevk: thoughts on the Ruby-inspired slot proposal?

[12:16:59.0000] <annevk>
Fine with me

[12:17:45.0000] <annevk>
Seems better than always slots, suspect that will not work for TC39 and also feels a bit unclean

[13:08:22.0000] <jyasskin>
tobie: I see 3 options: 1, the current proposal) interface I { [[SlotWithoutAttr]]; readonly attribute DOMString attrReflectsSlot; attribute DOMString computedAttr; }; In prose: computeAttr's getter MUST...; its setter MUST ....

[13:08:55.0000] <jyasskin>
tobie: 2, Domenic's option) interface I { [[SlotWithoutAttr]]; [Slot] readonly attribute DOMString attrReflectsSlot; attribute DOMString computedAttr; }; In prose: computeAttr's getter MUST...; its setter MUST ....

[13:09:50.0000] <jyasskin>
3, Ruby-style) interface I { [[SlotWithoutAttr]]; [ReflectReadonly] DOMString [[reflectedSlot]]; attribute DOMString computedAttr; }; In prose: computedAttr's getter MUST...; its setter MUST ....

[13:10:50.0000] <jyasskin>
Those are pretty similar, so I'd be fine with all of them. I *think* 2's my favorite.

[13:39:22.0000] <tobie>
jyasskin: it's funny (3) is quite a bit different the way you write from what I had imagined.

[13:44:58.0000] <jyasskin>
tobie: Your way's probably fine too?

[13:48:10.0000] <tobie>
jyasskin: ^ updated the issue

[13:50:36.0000] <jyasskin>
tobie: Thanks! Now I stand corrected: I don't like your Ruby-style option because it adds a line of declaration. It's still better than the status quo, but the other options DRY better.

[13:53:01.0000] <tobie>
jyasskin: frankly, I think they all have different tradeoffs.

[13:55:35.0000] <tobie>
jyasskin: if folks have interfaces that would showcase those well, send them to me; I'll just try them out and post the results somewhere.

[13:59:01.0000] <TabAtkins>
tobie: no idea, I'm on vacation, please write it up in an organized way in the issue and don't make decisions over Xmas-ish. 😀

[14:00:01.0000] <TabAtkins>
Also: who's in charge of @intenttoship, and can they figure out what part of the pipeline is (incorrectly) doing HTML parsing? https://twitter.com/intenttoship/status/942818202349948930

[14:00:35.0000] <tobie>
TabAtkins: :D

[14:01:12.0000] <tobie>
TabAtkins: I will not comment on the fact that you are answering irc during your vacation.

[14:01:44.0000] <TabAtkins>
We were resting between exhibits, I already delayed my answer by a few hours. 😀

[15:14:44.0000] <domfarolino>
Domenic: In light of https://github.com/whatwg/console/issues/121#issuecomment-352587781 do you think this issue can be closed?

[15:34:19.0000] <Domenic>
domfarolino: yeah, I would.

[15:42:57.0000] <Domenic>
Hmm I guess https://github.com/whatwg/console/issues/27 is mostly done, just need some -historical.html web platform tests and browser bugs perhaps?


2017-12-19
[22:44:25.0000] <MikeSmith>
botie, inform zcorpan about “Consider restricting <form accept-charset> to utf-8” https://github.com/whatwg/html/issues/3097 would it help if I added a use counter to the HTML checker?

[22:44:25.0000] <botie>
will do

[22:48:54.0000] <botie>
zcorpan, at 2017-12-19 06:44 UTC, MikeSmith said: “Consider restricting <form accept-charset> to utf-8” https://github.com/whatwg/html/issues/3097 would it help if I added a use counter to the HTML checker?

[22:57:20.0000] <domfarolino>
Domenic: Oh sorry was on mobile didn't see your message about #27

[22:58:43.0000] <domfarolino>
Agreed, forgot about that issue I'll get on it

[00:26:26.0000] <annevk>
kochi: any thoughts on the date for the F2F?

[00:27:02.0000] <annevk>
kochi: I guess the week of March 5?

[00:37:36.0000] <kochi>
annevk: yeah, the week of Feb.26-Mar.3 have conflicts with Domenic and Ryosuke, so March 5 sounds good.

[00:38:52.0000] <annevk>
kochi: bit unfortunate for Tom Dale and the location change might also not be great for framework developers :/

[00:39:19.0000] <annevk>
kochi: hopefully we can work out a better plan for that next time

[00:39:49.0000] <kochi>
annevk: yeah, but if we arrange properly, people can remotely dial-in/VC?

[00:39:51.0000] <annevk>
kochi: it might mean that we can't make much progress on new things

[00:39:56.0000] <annevk>
kochi: yeah maybe

[00:40:58.0000] <kochi>
so still I guess many are from US, Toronto would be best option?

[00:43:23.0000] <kochi>
annevk: how bad is it to set the date from Mar.5 - Mar.6?  It would make people move on Sunday, so Mar. 6-7 ?

[00:43:39.0000] <annevk>
kochi: well, not if there's all kinds of travel trouble

[00:43:48.0000] <annevk>
kochi: 6-7 seems ok to me

[00:44:25.0000] <annevk>
kochi: Mozilla has a slight preference for Tokyo at this point (we might have 6 people attend)

[00:44:36.0000] <annevk>
kochi: but we'll make it work either way

[00:44:57.0000] <kochi>
annevk: wow, I didn't feel Tokyo was so preferred <3

[00:46:37.0000] <kochi>
of course the best option for me is Tokyo, but considering everyone's travel, and timezone (some people might dial-in), I thought it would be the least option :)

[00:49:30.0000] <kochi>
annevk: In that case, as Ryosuke mentioned Tokyo is an option, let me propose Tokyo in the issue tracker?

[00:49:42.0000] <zcorpan>
MikeSmith: Maybe, if you know how to interpret the result of that data. The usage is pretty low per httparchive, but also it's sort of an opt-out mechanism, so it might be more useful to understand why it's being used.

[00:50:43.0000] <annevk>
kochi: sure

[00:51:32.0000] <kochi>
annevk: okay, then Tokyo, Mar. 6-7 is the primary option, and if no strong opposition is heard, let's go for the date/location.

[00:53:56.0000] <annevk>
kochi: k, maybe update the top post too

[00:54:04.0000] <kochi>
annevk: sure

[01:05:25.0000] <smaug____>
kochi: Tokyo sounds ok to me. I might travel to Taipei from there, or first to Taipei and then Tokyo.

[01:08:38.0000] <kochi>
thanks everyone!

[02:24:36.0000] <annevk>
miketaylr: hmm, I guess we forgot to talk about srcElement et al

[06:46:47.0000] <wanderview>
JakeA: damn it, your tests are better than mine

[06:47:28.0000] <JakeA>
wanderview: haha are you absolutely sure?

[06:47:35.0000] <wanderview>
no

[06:47:40.0000] <JakeA>
haha

[06:47:43.0000] <wanderview>
JakeA: but you have more of them

[06:48:45.0000] <wanderview>
bugzilla is sad today, so might not even be able to see our test

[06:53:19.0000] <annevk>
Domenic: I'll have a look at blog posts for "good first bug"

[06:53:26.0000] <annevk>
Domenic: please ping me if you're already on it

[06:55:10.0000] <annevk>
Domenic: https://blog.whatwg.org/github is updated

[06:56:54.0000] <annevk>
Domenic: https://blog.whatwg.org/html-standard-now-more-community-driven as well

[07:00:41.0000] <tantek>
annevk any chance that the old /web-apps/current-work/multipage links could be fixed to redirect to the right page rather than just the top of html.spec.whatwg.org ?

[07:00:50.0000] <tantek>
or maybe I should just file an issue

[07:02:06.0000] <annevk>
tantek: against https://github.com/whatwg/whatwg.org

[07:02:17.0000] <annevk>
tantek: they should redirect properly so yeah, that'd be a bug of sorts

[07:02:22.0000] <tantek>
ok

[07:13:34.0000] <tantek>
done: with example: https://github.com/whatwg/whatwg.org/issues/142

[07:33:41.0000] <annevk>
thanks

[08:16:38.0000] <annevk>
Domenic: the other issue with non-custom translate was that it would appear in a different place from custom commits and issues

[08:16:49.0000] <Domenic>
annevk: fixed via the new ordering thing

[08:17:01.0000] <annevk>
Domenic: okay

[08:21:14.0000] <Domenic>
annevk: if we can get TabAtkins to merge the Bikeshed PR do you think we can merge the whatwg/url boilerplate update commit? Or do you want to wait on figuring out LICENSE vs. LICENSE.md?

[08:21:33.0000] <Domenic>
Basically I want to figure out if I should work on the other 10-ish PRs, or hold off.

[08:22:38.0000] <annevk>
Domenic: I'd like the LICENSE to be fully confirmed

[08:22:50.0000] <annevk>
Domenic: best to only do this once

[08:22:50.0000] <TabAtkins>
Will merge now, dang mobile UI won't let me merge until Travis completes, and by then I've forgotten about it.

[08:22:55.0000] <Domenic>
TabAtkins: don't merge it!

[08:23:02.0000] <Domenic>
Apparently we're not ready, says annevk.

[08:23:08.0000] <Domenic>
I'll add a comment.

[08:23:14.0000] <TabAtkins>
Oh!

[08:23:15.0000] <TabAtkins>
Kk

[08:24:04.0000] <annevk>
Domenic: using the text/plain variant makes the most sense to me given that's what CC distributes itself

[08:24:29.0000] <Domenic>
Hmm I guess. But the SG has already expressed a preference for Markdown pretty strongly :P

[08:24:32.0000] <annevk>
Domenic: I don't really know though how that works with the Copyright statement at the top; I guess that's a modification you just need to make?

[08:25:08.0000] <Domenic>
One of the CC pages said that part was optional.

[08:26:26.0000] <Domenic>
I think it's like people are on vacation enough that we won't get this resolved until the new year, which is kind of a shame, but doing this all once is indeed better.

[08:32:36.0000] <Domenic>
It'd be nice to not include that copyright statement at the top in LICENSE because I'd really like to avoid updating those every year.

[08:36:15.0000] <annevk>
Domenic: good point

[08:36:26.0000] <annevk>
Domenic: if we did have to add it, would GitHub still detect it as such?

[08:36:59.0000] <annevk>
Domenic: in https://github.com/domenic/test-license-stuff/blob/master/LICENSE that is

[08:37:03.0000] <annevk>
(thanks for testing!)

[08:40:13.0000] <Domenic>
Might as well find out

[08:41:32.0000] <Domenic>
Header seems fine

[08:43:27.0000] <annevk>
Domenic: assuming there's not some kind of cache, yeah

[08:43:54.0000] <annevk>
Domenic: but yeah, avoiding a Meta: commit each year would be great

[08:58:27.0000] <othermaciej>
Domenic: in your test repo, did you determine whether LICENSE vs LICENSE.txt makes a difference to recognition by GitHub?

[08:59:08.0000] <othermaciej>
Domenic: I think GitHub autorecognition trumps formatting, so we defiitely want plaintext over .md

[08:59:41.0000] <Domenic>
othermaciej: I didn't but I will

[08:59:51.0000] <Domenic>
I find the URL-not-changing point by annevk compelling though

[09:02:02.0000] <Domenic>
othermaciej: .txt works too it seems

[09:03:18.0000] <othermaciej>
Domenic: not sure what the URL not changing point is. Is it that the repos currently contain files named just plain LICENSE?

[09:03:29.0000] <Domenic>
othermaciej: yeah exactly

[09:03:44.0000] <Domenic>
othermaciej: opinions on whether the changing-every-year copyright line is necessary?

[09:06:30.0000] <othermaciej>
Domenic: the first few popular open source projects that I checked on GitHub all have a copyright statement in the LICENSE file

[09:09:23.0000] <othermaciej>
Domenic: I randomly sampled 8 projects from the top 20 most popular on GitHub according to some list, and they all had a copyright notice in the LICENSE file

[09:09:45.0000] <Domenic>
Well, I guess if we want to be _conformist_, the path is clear... ;)

[09:09:45.0000] <othermaciej>
So it seems to be common practice. Whether it is absolutely required, I'd have to ask a lawyer, but I would be inclined to go with the common practice.

[09:10:04.0000] <Domenic>
Maybe include it without the year?

[09:11:06.0000] <othermaciej>
I have been told before that it's never correct to have a copyright notice without a year, but again I'd have to ask a lawyer to be sure

[09:11:18.0000] <Domenic>
Ah well.

[09:11:33.0000] <Domenic>
Maybe I'd feel better if we just delayed until 2018 so I don't have to do all these PRs twice

[09:11:43.0000] <Domenic>
Or maybe I should invent a tool that submits PRs to all repos to update their copyright year!

[09:12:01.0000] <othermaciej>
It would be ok to have an automated process update the year, either automatically on the 1st, or on the first commit in a given year

[09:12:27.0000] <Domenic>
Relevant XKCDs: https://xkcd.com/1319/ https://xkcd.com/1205/

[09:13:14.0000] <othermaciej>
Could make it a check on PRs for instance, that a PR must update LICENSE to the current year if not already up to date

[09:13:27.0000] <othermaciej>
heh, everyone knows programmers can't resist going into the shaded regions of that chart

[09:14:22.0000] <othermaciej>
ah, wait, I misunderstand the shading I think. But you know what I mean.

[09:16:36.0000] <astearns>
"Can I automate 90% of this 1-hour task so I could do it 50+ times a day?"

[09:18:10.0000] <Domenic>
^_^

[09:19:20.0000] <othermaciej>
Domenic: if you decide between LICENSE or LICENSE.txt and I'll update the sg repo to plaintext license in the matching filename. (Or feel free to just send a PR to that effect)

[09:19:49.0000] <Domenic>
othermaciej: I'll go with no extension. I'll work on the PR too.

[09:20:10.0000] <Shreya>
Domenic: Please review my pull request https://github.com/whatwg/html/pull/3303

[09:20:21.0000] <Domenic>
Shreya: yep, it's on my to-do list, hopefully today!

[09:51:24.0000] <othermaciej>
hmm, I just noticed that Console has multiple listed Editors in Workstreams.md, but all the policies assume one per Workstream

[09:58:48.0000] <wanderview>
I don't know how many times I can describe the same thing in https://github.com/whatwg/html/issues/3054

[10:00:01.0000] <wanderview>
/me gives up

[10:00:55.0000] <annevk>
wanderview: yeah dunno

[10:01:09.0000] <annevk>
wanderview: FWIW, the main thing I wanted to do here is to point out the fingerprinting concern

[10:01:38.0000] <wanderview>
annevk: its more than fingerprinting, no?  its tracking

[10:01:47.0000] <wanderview>
maybe thats the same thing

[10:01:49.0000] <annevk>
wanderview: we have some kind of fingerprinting logo we use to alert implementers to the fact that those features might need special consideration under more privacy-sensitive settings

[10:01:56.0000] <wanderview>
ok

[10:52:17.0000] <wanderview>
annevk: hah... now that person is asking that I define "privacy" for them

[11:03:46.0000] <Domenic>
I'm not sure what to do with that person... they are very aggressive

[11:04:00.0000] <Domenic>
But not in a way that crosses any lines, just ... really derails otherwise-productive discussions.

[11:10:41.0000] <annevk>
Just needs some coaching I hope

[11:10:43.0000] <jyasskin>
Amusing that "guest271314" doesn't believe people should worry about privacy. ;)

[11:13:47.0000] <othermaciej>
From reading the issue, WebKit would definitely need to disable or partition BroadcastChannel in some contexts when/if we implement it, to support our privacy features

[11:17:47.0000] <wanderview>
I wish github had a mute button

[11:20:21.0000] <othermaciej>
If it was good faith questions, I could at least explain the privacy property that WebKit aims to preserve with our Intelligent Tracking Prevention feature

[11:20:37.0000] <othermaciej>
Defining "privacy" in general seems way too broad though

[11:20:54.0000] <annevk>
I think they’re good faith

[11:21:18.0000] <annevk>
The problem is that person not doing some research first

[11:28:00.0000] <wanderview>
at least I know I'm not insane... I was starting to wonder if I was just typing gibberish

[11:28:35.0000] <wanderview>
well, probably not

[11:29:07.0000] <othermaciej>
I gave what I hope is a useful answer

[11:29:21.0000] <othermaciej>
at least about ITP, not on the more general "define privacy" question

[11:37:07.0000] <zcorpan>
annevk I don't have the bandwidth to review FP, but if chrome shipped the behavior change for allowfullscreen and it hasn't been reverted then it seems that should be done in the other engines also

[11:37:52.0000] <annevk>
zcorpan: I guess so

[11:38:15.0000] <zcorpan>
If FP does that to allowfullscreen then I guess my allowfullscreen PR can be closed, referencing the new one

[11:44:39.0000] <annevk>
Good point

[11:54:43.0000] <Domenic>
Today-I-learned [NoInterfaceObject] prevents x.constructor from existing.

[12:00:04.0000] <annevk>
I hope we can get rid of it completely still

[12:19:05.0000] <wanderview>
annevk: whether its intentional or not, I don't think this person is contributing constructively

[12:44:54.0000] <annevk>
wanderview: yeah...

[15:02:55.0000] <Domenic>
annevk: FYI https://github.com/whatwg/html/pull/3242 is nice but just waiting for tests.


2017-12-20
[16:00:21.0000] <tantek>
FWIW I say keep it as plain text. Markdown in templates is kinda junky.

[16:00:54.0000] <tantek>
also markdown was supposed to *be* plain text, so if you're ever asking the question of markdown vs. plain text, pick plain text becuase no "real" markdown would be breaking principle 1 and not actually be plain text

[18:17:42.0000] <miketaylr>
annevk: yeah :(, allhands as a manager get... busy fast. i'll shoot you an email tomorrow and maybe we can find some vidyo time (or just use email)

[23:14:52.0000] <domfarolino>
annevk: If I were to set {referrer: "http://same-origin.url:80"} on a request object `x`, would `x.referrer` be expected to return "http://same-origin.url" or "http://same-origin.url"

[23:17:13.0000] <domfarolino>
I ask because tests 8-11 always fail in http://w3c-test.org/fetch/api/request/request-init-001.sub.html and I feel like the test could be updated?

[23:39:54.0000] <annevk>
domfarolino: yeah those tests are wrong

[23:40:11.0000] <annevk>
domfarolino: the URL is indeed expected to be parsed and then serialized

[23:40:24.0000] <domfarolino>
annevk: ok I will submit a PR. Makes sense

[23:40:32.0000] <annevk>
domfarolino: I suspect browsers don't notice this since they locally don't run the tests over the default port

[23:40:42.0000] <annevk>
domfarolino: it's a longstanding issue with the WPT setup

[23:41:18.0000] <domfarolino>
That makes sense

[23:44:10.0000] <domfarolino>
annevk: So the tests now will accidentally be correct for non-default port usages, but are technically wrong, and would be right if they don't check the port right?

[23:45:31.0000] <annevk>
domfarolino: they would be right if they don't expect the default port but expect a port otherwise

[00:08:17.0000] <domfarolino>
annevk: ok. I’ll take a closer look at it tomorrow morning (for me) to mend it

[00:10:46.0000] <annevk>
domfarolino: nn then, I suppose

[01:06:45.0000] <Ms2ger>
foolip, I started looking at https://github.com/w3c/web-platform-tests/pull/8748 , but it ended up more complicated than expected. Could you review?

[02:07:11.0000] <annevk>
foolip: hmm, now I have to patch HTML's usage of cyphertext

[05:07:57.0000] <foolip>
Ms2ger: will do

[06:30:45.0000] <kochi>
/me feeling tough for making a decision.

[06:30:58.0000] <kochi>
(re webcomponents#713)

[06:32:01.0000] <annevk>
kochi: yeah, that's painful

[06:32:12.0000] <annevk>
kochi: I think you did the right thing though

[06:32:17.0000] <annevk>
if that helps

[06:33:32.0000] <kochi>
annevk: thanks, well, I think what's right would be having a place where everyone can join...

[06:36:05.0000] <kochi>
smaug____: you originally booked rooms in the Toronto office in the week of Feb. 19, but is it okay to ask you to book the week of Mar. 5?

[06:36:30.0000] <smaug____>
kochi: I just updated the reservation

[06:36:36.0000] <smaug____>
Mar 5-6

[06:36:40.0000] <kochi>
smaug____: thanks!!!!

[06:36:49.0000] <smaug____>
er, 6-7

[06:36:54.0000] <annevk>
kochi: that'd be the most right, yes

[06:37:02.0000] <smaug____>
kochi: 6-7 is right, right?

[06:37:03.0000] <annevk>
the rightest

[06:37:31.0000] <smaug____>
Tue, March 6, 2018 – Wed, March 7, 2018

[06:37:41.0000] <annevk>
hai

[06:38:23.0000] <kochi>
smaug____: yeah, if it's in Toronto, we'd prefer Mar. 6-7 (Tue-Wed)

[06:38:57.0000] <smaug____>
I guess I could extend that, just in case...

[06:39:47.0000] <smaug____>
Mon, March 5, 2018 – Wed, March 7, 2018

[06:41:43.0000] <kochi>
interesting, probably I'd travel to get there on Sunday, just in case for storm/delay, but then I can have a free Monday in Toronto.  maybe having a pre-meeting with people there is good.

[06:46:27.0000] <kochi>
I honestly don't understand Feature Policy, but I feel history API in iframes in shadow DOM can be controlled by Feature Policy.

[06:47:14.0000] <annevk>
kochi: well, maybe, but that'd make it even more complicated, right?

[06:47:33.0000] <kochi>
(re webcomponents#184)

[06:52:10.0000] <kochi>
annevk: (I need to understand Feature Policy first, but I imagine) the owner of <iframe> can specify whether  the history in iframe can join the joint session history, or make it have its independent session history.

[06:57:00.0000] <kochi>
/me goes to bed

[06:57:40.0000] <annevk>
kochi: yeah I guess, though within a closed shadow tree we wouldn't want to allow that

[06:57:46.0000] <annevk>
kochi: nn

[07:24:25.0000] <Ms2ger>
annevk, r? https://github.com/whatwg/html/pull/3308

[07:24:28.0000] <annevk>
Domenic: so we have a set of algorithms that are dangerous for other specification editors to touch; ideally we have some consistent messaging around these effectively deprecated internal APIs

[07:24:54.0000] <annevk>
domfarolino: so we could redirect them all to some Infra thingy perhaps but then we couldn't provide local issue filing support

[07:25:05.0000] <annevk>
Domenic: ^^ thoughts?

[07:25:16.0000] <annevk>
sorry domfarolino, though your thoughts are welcome too 😃

[07:25:36.0000] <Domenic>
annevk: example?

[07:25:49.0000] <domfarolino>
👍

[07:26:14.0000] <annevk>
Domenic: "same-origin domain" (and also the document.domain algorithm) came to mind today

[07:27:03.0000] <Domenic>
I guess just class="warning" seems OK to me; I'm not sure about the need for consistency, as you'll need to explain the reasons why they're bad in any case.

[07:28:18.0000] <annevk>
Ms2ger: r+ with some newline removal

[07:28:36.0000] <annevk>
Domenic: okay, I guess that's fine too

[07:28:46.0000] <annevk>
Domenic: I'm sensing some kind of pattern, but maybe too early

[07:29:38.0000] <Ms2ger>
annevk, any newlines in particular? (Did you forget to publish a review comment?)

[07:29:48.0000] <Ms2ger>
There it is, nvm

[07:29:58.0000] <annevk>
\o/

[07:30:03.0000] <annevk>
(I was a little slow)

[07:31:06.0000] <Ms2ger>
I stole that pattern of newlines from the next <ol>, is there a guideline published somewhere?

[07:33:33.0000] <annevk>
Ms2ger: I guess I should update https://github.com/whatwg/html/blob/master/CONTRIBUTING.md#source-formatting

[07:33:50.0000] <annevk>
Ms2ger: let me do that

[07:34:22.0000] <Ms2ger>
Okay, I looked at that, and if I'd paid more attention, that would have avoided half your comments :)

[07:35:20.0000] <Ms2ger>
(And fixed)

[08:57:10.0000] <wanderview>
/me never knows whether to ping people on IRC for WPT reviews or just hope they see it in their deluge of github mail...

[08:58:52.0000] <wanderview>
JakeA: jungkees: if either of you have a chance, I have a small WPT test fix I could use review on: https://github.com/w3c/web-platform-tests/pull/8743

[08:59:26.0000] <Shreya>
Can anyone please review https://github.com/whatwg/html/pull/3303?

[11:39:12.0000] <domfarolino>
Domenic: for that console formatting issue, are you thinking we should invoke the Symbol’s toString() instead of just throwing?

[11:42:02.0000] <domfarolino>
So like do a type check before just deferring to ToString() maybe

[11:51:31.0000] <Domenic>
domfarolino: I don't know about invoking toString(), maybe just composing our own string like "Symbol(" + symbol.[[Description]] + ")" ? But yeah a type-check.

[11:52:20.0000] <Domenic>
Wow Firefox really does print nothing, interesting.

[11:57:30.0000] <Domenic>
annevk: force-pushed over https://github.com/whatwg/html/pull/3305, I should've done a new commit so it'd email you, oh well.

[11:58:43.0000] <domfarolino>
Domenic: Hm alright wouldn’t that produce an identical string to toString() is there a reason to not invoke it? Just curious (not super familiar with Symbols yet)

[11:59:11.0000] <Domenic>
domfarolino: it'd differ in the case of someone overriding Symbol.prototype.toString. I guess it's worth testing what browsers do in those cases.

[12:01:57.0000] <Domenic>
domfarolino: it looks like ES already has something for us: https://tc39.github.io/ecma262/#sec-string-constructor-string-value

[12:13:50.0000] <annevk>
Domenic: I was out too so...

[12:14:06.0000] <annevk>
Domenic: I'll be out until January 3 or so soonish

[12:14:14.0000] <Domenic>
Ah OK, sounds good

[12:14:18.0000] <annevk>
Domenic: probably won't bring my laptop either

[12:14:20.0000] <Domenic>
I'll be similar starting Friday

[12:15:21.0000] <Domenic>
annevk: do you want to help shepherd https://github.com/whatwg/html/pull/3308 through to the end (addColorStop) or should I familiarize myself with everyone's review comments?

[12:16:53.0000] <domfarolino>
Domenic: Good call. Will check out link soon, driving for a bit soon and on mobile now

[12:17:36.0000] <annevk>
Domenic: I guess I'm happy to leave it until the new year; I suppose Ms2ger isn't in a hurry either for a clarification PR

[12:17:44.0000] <Domenic>
ah ok

[12:17:48.0000] <annevk>
Domenic: I'm happy to finish it for Ms2ger at that point

[12:18:22.0000] <annevk>
Domenic: that is, it seems junov made some good points that require either follow-up issues or be addressed directly

[12:49:34.0000] <annevk>
/me gives a lone vote for the Paris F2F backup plan

[12:50:06.0000] <annevk>
Being able to go to a F2F by train would be the best, although likely I'd still end up flying

[14:05:17.0000] <adiabatic>
I'm trying to place a <style> element as a child of <body> because I'm lazy and want to keep some CSS with the blog post that it applies to. That said, the w3c validator says that <style> may be used where metadata content is expected…but the diagram in §3.2.5.2 shows that some metadata content is also flow content like <p> is…

[14:05:52.0000] <adiabatic>
…and the w3c validator says: "Contexts in which element style may be used: … In the body, where flow content is expected."

[14:06:00.0000] <adiabatic>
So why am I getting an error?

[14:06:20.0000] <adiabatic>
(I get a similar error from validator.nu)

[14:07:41.0000] <Domenic>
adiabatic: In the HTML Standard (not any W3C forks) <style> is not allowed inside <body>. I'm not sure about those checkers but I do know https://checker.html5.org/ is up to date with that.

[14:12:52.0000] <adiabatic>
OOoooh, OK. If <style> were metadata _and_ flow content like <noscript> it'd say. Thanks!

[14:13:20.0000] <adiabatic>
That's kind of a shame; it seems to work in all the browsers I use…

[14:17:31.0000] <Domenic>
Yeah, it works in browsers, just is bad for performance, so it causes validation failures

[14:18:31.0000] <adiabatic>
why, because it can trigger a whole-page repaint when the page is half- or 3/4 downloaded?

[14:18:52.0000] <Domenic>
Exactly

[14:20:13.0000] <adiabatic>
weird. I'd figure "it'd make your page slow" would be cause for a warning, not an error

[14:22:41.0000] <Domenic>
I mean, it's way more serious than using <strong><em>foo</strong></em> or similar, as it actually affects your users.


2017-12-21
[16:29:36.0000] <domfarolino>
Domenic: oh SymbolDescriptiveString sounds great!

[16:35:50.0000] <domfarolino>
Or really just String() too for simplicity I guess hah

[18:59:37.0000] <domfarolino>
Interesting, I found that `new Request("", {referrer: Symbol("Test")})` kills the content window in chrome and disconnects the DevTools from the page, instead of throwing a TypeError (same for all request init members)

[19:08:37.0000] <domfarolino>
K it doesn't happen in Canary so not as interesting...but good!

[20:08:49.0000] <bathos>
curious if anybody can shed light on something in the spec for me

[20:09:37.0000] <bathos>
in § 12.2.6.1, "Creating and inserting nodes", when foster parenting is enabled:

[20:09:47.0000] <bathos>
https://html.spec.whatwg.org/multipage/parsing.html#creating-and-inserting-nodes:foster-parent

[20:10:21.0000] <bathos>
at step 5 one knows that there is an open table. it says:

[20:10:24.0000] <bathos>
"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."

[20:10:46.0000] <bathos>
I’m unsure what circumstance can occur where that table could not have a parent node.

[20:29:08.0000] <bathos>
oh, derp. it’s actually made explicit in a note right below:

[20:29:11.0000] <bathos>
"These steps are involved in part because it's possible for elements, the table element in this case in particular, to have been moved by a script around in the DOM, or indeed removed from the DOM entirely, after the element was inserted by the parser."

[03:58:31.0000] <annevk>
JakeA: are you also cross-checking Safari with WPT? Would be interesting to know what kind of bugs are not covered there

[03:58:53.0000] <JakeA>
annevk: writing some new tests right now :D

[04:01:08.0000] <annevk>
JakeA++

[06:06:00.0000] <wanderview>
JakeA: I guess STP implemented fetch.destination... I wonder if edge implements that yet or if webkit is the first

[06:06:11.0000] <wanderview>
fetch request.destination

[06:14:02.0000] <Ms2ger>
annevk, hey, anything blocking https://github.com/whatwg/html/pull/3308 ?

[06:14:55.0000] <wanderview>
JakeA: I wonder if they have a test for request.destination... that would be nice to have

[06:40:47.0000] <annevk>
Ms2ger: I was thinking there is no particular rush

[06:41:04.0000] <Ms2ger>
No, that's true

[06:41:34.0000] <annevk>
Ms2ger: so I wanted to look into the things  Justin mentioned and maybe address those

[06:42:18.0000] <annevk>
Ms2ger: as it happens vacation time is starting so might not land until the first week of 2018 or so

[06:42:49.0000] <Ms2ger>
Enjoy the holidays :)

[06:48:36.0000] <JakeA>
wanderview: I don't think there are any tests currently :/

[06:49:47.0000] <wanderview>
JakeA: they've made some other WPT test changes recently

[06:50:36.0000] <wanderview>
well, I noticed one I was not thrilled about

[06:50:54.0000] <JakeA>
wanderview: oh?

[06:51:40.0000] <wanderview>
JakeA: they removed the check for FetchEvent.isReload and replaced it with a check that its not there... which does match the spec now... but we have a spec issue open about this and we talked about in previous F2F meetings leaving the test in until the replacement could be spec'd

[06:51:47.0000] <annevk>
Ms2ger: you too!

[06:52:19.0000] <JakeA>
wanderview: hmm, yeah, that's not so good

[06:53:00.0000] <JakeA>
wanderview: Edge doesn't support URLSearchParams so I'll find something else

[06:53:29.0000] <wanderview>
JakeA: I mean... they're not completely wrong and I'm not asking for it to be backed out... but I hope we see more spec issue participation

[06:53:39.0000] <JakeA>
agreed

[06:54:10.0000] <wanderview>
JakeA: FWIW, I think MS said they are working on URLSearchParams for interop on SW... so maybe its ok?

[06:55:24.0000] <wanderview>
JakeA: searchParams are also used in about-blank-replacements.https.html (I just wrote that), clients-matchall-order.https.html, and claim-with-redirect.https.html

[06:55:45.0000] <JakeA>
wanderview: ahh ok, will leave it as is

[06:56:16.0000] <wanderview>
JakeA: if they ask us to change it we can... but I'm fairly certain real web sites assume its there in service workers

[07:07:56.0000] <Ms2ger>
wanderview, if there's ongoing discussion, I'd remove the check for non-support too

[10:25:54.0000] <adrianba>
searchParams in Edge -> https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8993198/

[10:26:23.0000] <adrianba>
it says fixed but not flighted (I don't know how that gets updated) but I don't think that's true - pretty sure the latest flights include support

[11:52:54.0000] <Domenic>
welcome to #whatwg, adrianba ^_^

[11:55:33.0000] <adrianba>
\o/

[12:20:53.0000] <annevk>
🎉

[12:41:04.0000] <othermaciej>
Newbie git/GitHub question: what is the best way to rebase a branch to current master?

[12:41:33.0000] <othermaciej>
I know that when your PR has conflicts, GitHub has a GUI way to do it, but I have a branch without conflicts that I'd like to rebase

[12:46:23.0000] <domfarolino>
annevk: Why does "websocket" not exist in the Request mode enum? Will you never get a chance to see this value in JS?

[12:51:34.0000] <domfarolino>
othermaciej: You're looking for a way to do it via UI?

[12:51:53.0000] <othermaciej>
domfarolino: command-line is fine - I am not sure of the best command-line invocation

[12:53:48.0000] <domfarolino>
Hm, I guess I always just run `git rebase origin/master` from the current branch unless I'm misunderstanding something

[12:54:47.0000] <othermaciej>
OK, I will try that!

[12:55:02.0000] <othermaciej>
I am seriously such a git newbie that I did not know this was a thing

[12:55:12.0000] <domfarolino>
haha no problem! hope it works

[13:04:42.0000] <domfarolino>
othermaciej: I almost always use `rebase` instead of `merge` to avoid a merge commit

[13:06:38.0000] <domfarolino>
annevk: Oh, yep just saw the note which describes that!

[13:10:08.0000] <othermaciej>
git rebase seems to put me in a weirdly broken mode

[13:10:17.0000] <othermaciej>
do I need to rebase the remote branch instead of the local one or something?

[13:24:14.0000] <domfarolino>
othermaciej: Hm are you in detached head state? You should be in the base you want to rebase when running `git rebase`, did it give you any errors and tell you to fix them then continue with `git rebase --abort` or `--continue`?

[13:24:47.0000] <othermaciej>
My local git experts say I need to either force push the result of my rebase, or merge master instead of rebasing

[13:26:30.0000] <domfarolino>
othermaciej: Ohh yes force push is prob required to overwrite your old commit with the rebase + new commit. That's why it isn't always good to use it on branches other people are also working on I believe

[13:26:49.0000] <othermaciej>
merge did what I wanted

[13:26:51.0000] <domfarolino>
because then the histories diverge, however it can be convenient when working on something alone

[13:27:06.0000] <domfarolino>
othermaciej: That's good, yeah I just don't like the extraneous merge commit

[13:28:47.0000] <othermaciej>
The PR will ultimately get squash merged so I think the extra commit is ok

[13:31:51.0000] <domfarolino>
`rebase` rebases old commits on a new tip, however the "old" commits that are replayed have new updated hashes. When updating a branch the main diff b/w rebase and merge is the order in which updating happens. Merge keeps your stuff and brings the new stuff in on top. Rebase brings in the old stuff as if your changes never existed, then replays them on top.

[13:32:13.0000] <domfarolino>
othermaciej: Yeah agreed

[13:32:54.0000] <domfarolino>
othermaciej: hopefully that helped a little sorry it put you in a broken state!

[13:34:33.0000] <othermaciej>
domfarolino: no worries, now I will better understand how to do this in the future


2017-12-22
[00:59:09.0000] <Shreya>
Domenic: I have made the changes as you suggested. You can check it now https://github.com/whatwg/html/pull/3303

[02:35:54.0000] <kochi>
As I commented on webcomponents#713, the next WC F2F will be at Tokyo, Mar. 5-6 (Mon-Tue).

[02:37:08.0000] <kochi>
I reserved a room, which should be enough capacity, I guess ~30 people get together?  (the room is like ~70 people)

[02:37:57.0000] <kochi>
/me will figure out the requirement for building security, etc. and call for participation.

[02:41:44.0000] <kochi>
Maybe as everyone is in holiday week or year-end/new year vacation, sending such announcements will be buried at the bottom of inbox - will announce again next year.

[04:45:10.0000] <annevk>
Thanks kochi


2017-12-23
[15:53:11.0000] <GPHemsley>
annevk, foolip: Just so you know, @-ing me on GitHub does very little to get my attention, since I usually already get all e-mail from the repo... If you actually need me to look at something, you're better off pinging me here.


2017-12-24
[23:47:38.0000] <foolip>
GPHemsley: it's possible to filter for @mentions, which is really necessary to ever notice important things on GitHub.

[23:49:50.0000] <foolip>
GPHemsley: it's sent to/from some specific email address

[01:03:26.0000] <TimothyGu>
Is there a place I can find bzbarsky?

[01:20:16.0000] <KiChjang_>
TimothyGu, try moznet?

[10:23:33.0000] <GPHemsley>
TimothyGu: For the record, he's bz there.

[10:24:08.0000] <GPHemsley>
foolip: I'm not sure what I would do with that, since I already have the e-mails filtered into a hierarchical structure. :/

[14:39:48.0000] <TimothyGu>
KiChjang GPHemsley: thanks


2017-12-25
[16:18:33.0000] <mel00010>
I've been working on implementing an entirely new HTML layout engine, and up until recently was blissfully unaware of the fork of the HTML specification between the W3C and WHATWG.  So far, I have been following the W3C HTML5 specification.  After some research, I have decided to follow the WHATWG specification instead, as it appears more authoritative.  I've only implemented the tokenization stage of parsing and some of

[16:18:33.0000] <mel00010>
the common microsyntaxes so far.  Are there any serious differences (things I should re-implement) between the specifications that I should be aware of?

[16:18:50.0000] <mel00010>
Sorry if this is the wrong place for this question BTW

[16:21:39.0000] <mel00010>
Also, this is an independent project, mostly for fun and to learn the specification inside out

[17:17:14.0000] <Domenic>
mel00010: https://diffofhtmls.herokuapp.com/ should help. Glad to hear you found your way to the right place :).

[17:29:50.0000] <mel00010-mobile>
Thanks.  This fork issue is really annoying.  It defeats the whole point of standards

[21:39:01.0000] <GPHemsley>
mel00010: I don't think you'll find anyone here who will disagree with you on that point ;)

[23:42:53.0000] <MikeSmith>
SimonSapin: about https://github.com/whatwg/html-build/issues/144 I wonder if the dfn backlink behavior works for you

[23:44:08.0000] <MikeSmith>
that is, the behavior where if you click on the text of a dfn’ed term, a pop-up is shown with all the places in the space that reference that term

[23:47:41.0000] <MikeSmith>
regardless, I think that message indicates you need to rebuild your wattsi binary from the latest sources

[23:49:45.0000] <MikeSmith>
because wattsi is what generates that xrefs.json file, but it’s only been doing that since June

[23:49:52.0000] <MikeSmith>
https://github.com/whatwg/wattsi/commit/b57d52cef308e8e3b249034d314e19ee6e3a824a

[23:50:41.0000] <MikeSmith>
so if you’ve not rebuilt your wattsi after June, then it’s not generating that expected xrefs.json file

[23:51:47.0000] <MikeSmith>
I guess we should probably add some code to the build script to catch that case and emit a message saying “You need to rebuild your wattsi”


2017-12-30
[01:25:39.0000] <bathos>
Got an HTML parsing question

[01:26:21.0000] <bathos>
given this input, assuming a fragment with a generic context element like <div>, what is the correct structure to parse?

[01:26:24.0000] <bathos>
`<li>a<li>b<ul><li>c<ol>d`

[01:26:49.0000] <bathos>
I expected it to be `<li>a</li><li>b<ul><li>c<ol>d</ol></li></ul></li>`

[01:27:25.0000] <bathos>
But both Chrome and FF give `<li>a</li><li>b<ul><li>c</li><ol>d</ol></ul></li>` (closing the "c" li when they hit <ol>)

[01:27:42.0000] <bathos>
I can’t find where that occurs in the "in body" insertion mode

[01:29:03.0000] <bathos>
it seems like the only thing the <ol> should close would be an open <p>

[01:31:50.0000] <bathos>
nm, I’m glad I’ve gotten into the habit of making a fool of myself in here rather than the github issues — copy & pasted the wrong input repeatedly. chrome and ff do give the res I expected

[01:33:12.0000] <bathos>
(should probably stop working on this and get back to black mirror, my head is goo)