2016-03-01
[21:35:18.0000] <rniwa>
annevk: yt?

[21:35:30.0000] <rniwa>
hayato: who works on custom elements spec now?

[21:36:43.0000] <annevk>
rniwa: about to get out of bed, but not really around for another two hours or so, unless it's something quick?

[21:36:59.0000] <rniwa>
annevk: fyi, i triaged a bunch of custom elements spec bugs

[21:37:09.0000] <rniwa>
annevk: and added v1 flags everywhere deemed necessary

[21:37:35.0000] <annevk>
great, I'll take a look today

[21:37:39.0000] <rniwa>
annevk: thanks.

[21:38:00.0000] <rniwa>
annevk: i'm somewhat concerned that custom elements spec hasn't been updated in the past month or two

[21:38:31.0000] <annevk>
We could maybe start putting it in DOM and HTML now

[21:39:03.0000] <annevk>
And fix things as we go

[21:39:18.0000] <rniwa>
annevk: lifecycle callback stuff certainly needs to go to WebIDL

[21:39:39.0000] <rniwa>
annevk: and DOM needs to enqueue tasks

[21:40:08.0000] <annevk>
True, it's a holy trifecta

[23:01:18.0000] <hayato>
rniwa: Yeah, we, google, are aware that it's very unsatisfying situation that custom elements hasn't been updated.

[23:24:49.0000] <annevk>
hey hayato, good afternoon

[23:25:14.0000] <hayato>
annevk: hi

[23:26:05.0000] <annevk>
hayato: still slowly wrapping my head around all the concepts to figure out how to best merge things into DOM/HTML etc.

[23:26:16.0000] <annevk>
hayato: plan to mostly work on that today

[23:26:21.0000] <annevk>
(it's still early here)

[23:26:56.0000] <hayato>
annevk: thanks. I guess that's tough work.

[23:29:01.0000] <annevk>
hayato: it's a little hard yes, especially figuring out when the various algorithms in Shadow DOM should run

[23:29:19.0000] <annevk>
hayato: unlike you, I haven't implemented it several times over the past five years 😃

[23:29:41.0000] <hayato>
I'll take a look issues filed on the spec later.

[23:29:54.0000] <annevk>
Thanks

[23:30:25.0000] <annevk>
I started filing some issues against the HTML Standard too, sort of as a summary of what we should do / what we need to resolve

[23:30:49.0000] <hayato>
And I'll have yet another section to clarify a lot of things, mentioning iframe, script, title attribute on style, and so on...

[23:30:57.0000] <annevk>
A lot of decisions of not sharing anything with the shadow DOM breaks the composition use case quite badly

[23:31:51.0000] <annevk>
I wonder how important the composition use case is, if it's important we should make "open shadow trees" much more similar to normal "document trees" maybe, with <iframe> having history there, etc.

[23:34:01.0000] <hayato>
I see.  Yeah, there has been always a debate between encapsulation vs *open* for better composition.

[03:19:00.0000] <Ms2ger>
annevk, fyi https://github.com/w3c/web-platform-tests/pull/2639

[03:31:10.0000] <erlehmann_>
i just noticed that lists.whatwg.org is offline and there are no redirects put into place

[03:31:21.0000] <erlehmann_>
for example, https://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033914.html has moved to https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Nov/0186.html

[04:21:10.0000] <annevk>
http://nolanlawson.com/2016/02/29/high-performance-web-worker-messages/ is sad

[04:51:08.0000] <Domenic>
PR list is finally looking manageable

[04:51:58.0000] <zcorpan>
no unread notifications \o/

[04:52:19.0000] <zcorpan>
time for a coffee

[04:52:39.0000] <Domenic>
zcorpan: can you finish up the <link> in body PR for igrigorik maybe?

[04:58:31.0000] <annevk>
Domenic: https://github.com/tc39/ecmascript_sharedmem/issues/65 might be of interest

[05:01:04.0000] <zcorpan>
Domenic: yes, it's my currently open tab :-)

[05:01:10.0000] <Domenic>
\o/

[05:12:08.0000] <nox>
Domenic: I wonder if it's because Spring is coming.

[05:12:15.0000] <nox>
Domenic: Same thing happened to Servo's queue.

[05:20:57.0000] <jgraham>
jdm happened to Servo's queue

[05:22:03.0000] <nox>
That.

[05:34:21.0000] <nox>
Is there some summary of which Exposed combinations there are in the platform?

[05:55:54.0000] <annevk>
nox: there's 4 globals, workers are usually grouped

[05:56:28.0000] <nox>
annevk: Yeah I know, just need which combinations are actually used to implement Exposed in Servo.

[05:56:57.0000] <annevk>
nox: can't make it generic?

[05:57:49.0000] <nox>
annevk: I could, just don't want to.

[05:57:55.0000] <annevk>
Anyway, not sure about an exhaustive list of all combinations, best to grep a browser engine I guess

[05:59:27.0000] <nox>
annevk: Did the Constructor on XMLDocument go away?

[05:59:45.0000] <annevk>
nox: I don't think it ever had one

[05:59:49.0000] <nox>
(We have one in Servo but can't find it in DOM.

[05:59:51.0000] <nox>
Weird.

[05:59:57.0000] <nox>
Ms2ger: ^

[06:02:19.0000] <Ms2ger>
Huh

[06:03:09.0000] <nox>
Ms2ger: Filing.

[07:56:10.0000] <annevk>
Domenic: I cannot make much sense of https://mxr.mozilla.org/mozilla-central/source/js/src/vm/StructuredClone.cpp

[07:56:30.0000] <Domenic>
oh boy

[07:57:25.0000] <Domenic>
So I ctrl+fed for "error" and didn't seem to find anything specifically prohibiting Error objects, which supports my hypothesis. Looking more...

[07:58:38.0000] <annevk>
There's a couple other files too, but I cannot make much sense of any of them

[07:59:23.0000] <Domenic>
https://mxr.mozilla.org/mozilla-central/source/js/src/vm/StructuredClone.cpp#1178

[07:59:35.0000] <Domenic>
I think it is keying off of some equivalent of ES5's [[Class]]

[07:59:46.0000] <Domenic>
So it'll only do own-property cloning on things that return "[object Object]"

[07:59:52.0000] <Domenic>
which is how it excludes all the other things

[08:00:12.0000] <annevk>
That does kinda match what HTML used to have

[08:00:16.0000] <Domenic>
("returns object Object" is not precise these days because of @@toStringTag. But it seems the engine has some concept similar to that.)

[08:00:36.0000] <Domenic>
Yeah, ES just totally blew up that infrastructure, lol

[08:01:08.0000] <annevk>
"any internal slot" seems okay, perhaps with two example objects in a note

[08:01:32.0000] <Domenic>
Yeah, I think that's probably going to be our best bet

[08:02:04.0000] <Ms2ger>
I see some GetBuiltinClass

[08:02:21.0000] <Ms2ger>
842  * Enumeration describing possible values of the [[Class]] internal property

[08:02:22.0000] <Ms2ger>
843  * value of objects.

[08:02:23.0000] <annevk>
Once we define IDL better we should also fix that integration a bit

[08:02:31.0000] <annevk>
All in due course I guess

[08:02:45.0000] <Domenic>
Very interesting how ES just totally removed this piece of infrastructure. Arguably for good reasons, but it does make things rather different.

[08:04:59.0000] <Domenic>
https://mxr.mozilla.org/mozilla-central/source/js/src/jsfriendapi.cpp#267 is interesting

[08:29:51.0000] <Domenic>
Whooooo wants to test Safari for me!! https://github.com/whatwg/html/issues/775#issuecomment-190796607

[08:39:04.0000] <miketaylr>
Domenic: i can, sec

[08:39:51.0000] <miketaylr>
Domenic: https://cloudup.com/cACI0kI4fSV

[08:39:52.0000] <astearns>
https://www.irccloud.com/pastebin/B9sOMoOh/

[08:40:50.0000] <miketaylr>
heh, 3rd behavior

[08:41:03.0000] <Domenic>
wait what

[08:41:31.0000] <Domenic>
Maybe these don't have constructor names in Safari?

[08:41:44.0000] <Domenic>
Hmm wait I brought my iPad to work, I can maybe do this

[08:43:02.0000] <Domenic>
OK yeah

[08:45:46.0000] <Domenic>
table updated, thanks all

[08:57:12.0000] <gsnedders>
Hmm. Is "BUT LET'S KISS." inappropriate to have on a slide?

[08:58:52.0000] <miketaylr>
gsnedders: depends, maybe the slide is a presentation meant for your significant other

[08:59:22.0000] <jgraham>
In that case it's clearly inappropriate

[08:59:32.0000] <jgraham>
I mean I'm not a relationship expert

[08:59:50.0000] <jgraham>
But if you are mainly communicating through powerpoint I think it might be beyond repair

[08:59:55.0000] <miketaylr>
^^

[09:00:21.0000] <annevk>
gsnedders: with KISS not being the abbreviation?

[09:01:06.0000] <gsnedders>
annevk: with KISS being the abbreviation

[09:01:53.0000] <gsnedders>
But it *is* a pun, made unclear by the capitalisation of all of it

[09:02:17.0000] <miketaylr>
you can pivot to a different pun http://www.post-gazette.com/image/2014/08/19/ca19,13,2172,1391/20140819hokissmag.jpg

[09:02:30.0000] <miketaylr>
but those guys are pretty gross

[09:03:06.0000] <miketaylr>
maybe i'm just jealous of that leather armor

[09:05:47.0000] <gsnedders>
hah

[09:09:42.0000] <gsnedders>
heh, my SO doesn't see how anyone could have any problem with it, thinking it can't really be construded as objectifying any specific person or group given it makes no statement as to who is being kissed.

[09:11:13.0000] <miketaylr>
the way to diffuse any potential drama it is to have a picture of kittens kissing in the slide

[09:11:43.0000] <miketaylr>
aww http://40.media.tumblr.com/tumblr_lxpj8u62Rh1r9z84ho1_500.jpg

[09:31:00.0000] <annevk>
Domenic: if you find some time, I would love for you to take a look at https://github.com/whatwg/html/pull/323 and figure out how you'd fix it

[09:31:19.0000] <Domenic>
Hmm OK.

[09:31:23.0000] <Domenic>
Doing custom elements right now.

[09:31:40.0000] <annevk>
Domenic: there's no rush at all, I'm just having such a hard time to get my head around it

[09:48:40.0000] <TabAtkins>
gsnedders: In general, avoid sexualized jokes entirely.

[09:48:43.0000] <annevk>
TabAtkins: FWIW, it still says [ENCODING] but it does now link to the right place

[09:48:59.0000] <TabAtkins>
annevk: Yeah, that's intentional.  Again, minimum-effort until things are fixed.

[09:49:11.0000] <TabAtkins>
I want to just rip out the two lines handling this when SpecRef fixes things.

[09:49:52.0000] <gsnedders>
TabAtkins: see, that's what I would go for, really.

[10:06:38.0000] <JonathanNeal>
I’m looking for the latest Selectors API. Will #Element.findAll return a collection that extends Array?

[10:07:08.0000] <annevk>
JonathanNeal: see https://dom.spec.whatwg.org/

[10:07:21.0000] <annevk>
JonathanNeal: that's the idea, but it's not reality yet, subclassing is taking its time

[10:09:26.0000] <JonathanNeal>
Oh, this looks different than what I saw before. Thanks, annevk! I thought .query & .queryAll would return a live collection and .find & .findAll would return a non-live collection.

[10:10:04.0000] <annevk>
JonathanNeal: find/findAll are gone

[10:10:24.0000] <TabAtkins>
They were renamed to query/All() because of the conflict with window.find().

[10:10:27.0000] <annevk>
JonathanNeal: and new live collections are also gone (mostly, hopefully)

[10:12:10.0000] <JonathanNeal>
Got it, and Elements being a subclass of Array means it doesn’t inherit changes to Array prototype?

[10:12:53.0000] <TabAtkins>
No, it *does* mean that.

[10:12:53.0000] <annevk>
JonathanNeal: I don't know, is that how subclassing is different from proto chaining?

[10:12:59.0000] <TabAtkins>
Subclass means proto-chaining.

[10:13:11.0000] <annevk>
Yeah I thought so

[10:13:28.0000] <JonathanNeal>
So, in a sense, Elements.prototype = new Array()?

[10:13:56.0000] <TabAtkins>
I think it's closer to Elements.prototype = Object.create(Array.prototype)

[10:15:19.0000] <JonathanNeal>
/me was too old school to remember Object.create. Nods.

[10:41:10.0000] <Domenic>
No, it's in fact closer to Elements.prototype.__proto__ = Array.prototype

[10:41:18.0000] <Domenic>
(and Elements.__proto__ = Array)

[10:41:42.0000] <Domenic>
I seem to be accidentally rewriting the custom elements spec

[10:48:52.0000] <TabAtkins>
Domenic: Your first line requires *creating* Elements.prototype somehow first; my line does so, by making it an empty object with its proto set to Array.prototype.

[10:49:08.0000] <TabAtkins>
I did leave out the proto shenanigans of the constructor functions, yeah.

[10:49:46.0000] <caitp>
those proto shenanigans are important for subclassing

[10:50:02.0000] <TabAtkins>
I understand. I didn't say that I left it out intentionally.

[10:55:41.0000] <Domenic>
TabAtkins: your line overrides it. All functions have a .prototype

[11:00:37.0000] <nox>
https://github.com/whatwg/html/issues/775#issuecomment-190851825

[11:06:16.0000] <Domenic>
yeah thanks for saving the day there

[11:30:34.0000] <TabAtkins>
Welp, I'm an idiot. Just figured out why I was getting 15s processing times on an empty spec.

[11:31:02.0000] <TabAtkins>
Turns out the invoking the HTML parser on a large CSS file hits some degenerate behavior and makes everything go very slowly.

[11:31:20.0000] <TabAtkins>
Welp, I'm an idiot. Just figured out why I was getting 15s processing times on an empty spec.

[11:32:33.0000] <gsnedders>
TabAtkins: so next PyPy and lxml releases should hopefully work together; will be interesting to revisit performance then

[11:46:34.0000] <rniwa>
dglazkov: yt?

[12:13:09.0000] <rniwa>
Domenic: yt?

[12:13:17.0000] <Domenic>
rniwa: yep

[12:13:35.0000] <rniwa>
Domenic: do you know who is responsible for updating custom elements spec these days?

[12:14:17.0000] <Domenic>
rniwa: myself and Koji probably; we have a meeting with Hayato to discuss that tomorrow

[12:14:25.0000] <Domenic>
rniwa: I am about 3/4 of the way through fixing a lot of things

[12:14:32.0000] <rniwa>
Domenic: okay

[12:14:40.0000] <rniwa>
Domenic: I'm more than happy to help out

[12:14:53.0000] <Domenic>
rniwa: I thought I'd do just a quick PR to get your text into the spec and then I kept updating things and now like 60% of the spec is new

[12:14:57.0000] <rniwa>
Domenic: but it's getting really hard to implement custom elements in WebKit without having anything concrete in the spec

[12:14:59.0000] <Domenic>
rniwa: that'd be great!

[12:15:15.0000] <rniwa>
Domenic: okay

[12:15:16.0000] <Domenic>
rniwa: let's land my PR then it should be easier to implement the remaining problematic parts

[12:15:41.0000] <rniwa>
Domenic: e.g. I could just start pushing PR for issues that aren't getting much traction

[12:16:07.0000] <rniwa>
Domenic: also, there is a lot of spec debt now.

[12:19:55.0000] <nox>
https://github.com/whatwg/html/issues/775#issuecomment-190885243

[12:20:00.0000] <nox>
Domenic: Am I still right?

[12:20:51.0000] <Domenic>
nox: seems likely, attention on custom elements for now...

[12:21:11.0000] <nox>
Domenic: Good luck.

[12:59:35.0000] <Domenic>
I am feeling optimistic about integrating custom elements into DOM and HTML now

[12:59:40.0000] <Domenic>
Except for parsing. I am not optimistic about that.

[13:00:21.0000] <dglazkov>
I AM HERE!!!

[13:00:22.0000] <dglazkov>
wait

[13:00:25.0000] <dglazkov>
everything is solved

[13:01:37.0000] <Domenic>
I dunno somehow I just cloned the repo and one thing led to another and it just kinda happened

[13:02:05.0000] <dglazkov>
that's how it always goes. 3 years later you're the HTML spec editor.

[13:02:27.0000] <Domenic>
so true. so, so true.

[13:02:38.0000] <nox>
Is it known that for document.createElement(), Safari returns <undefined></undefined>?

[13:02:42.0000] <nox>
I think I died inside a bit.

[13:02:48.0000] <Domenic>
that's amazing

[13:03:12.0000] <nox>
Domenic: :D

[13:03:21.0000] <Domenic>
I guess Blink only recently fixed our `optional` handling

[13:03:21.0000] <nox>
Domenic: I was complaining to a friend about that all() thing,

[13:03:28.0000] <nox>
told me "meh, everything is optional in JS",

[13:03:31.0000] <nox>
wanted to prove him wrong.

[13:03:35.0000] <nox>
And then this happened.

[13:03:36.0000] <nox>
-_-

[13:16:04.0000] <caitp>
nox: that's since been fixed :x

[13:16:14.0000] <nox>
caitp: Nice to know.

[13:19:42.0000] <nox>
Domenic: Btw, GitHub understands language "webidl", if you want to colorise code snippets.

[13:19:58.0000] <Domenic>
nox: thanks, updated

[13:24:15.0000] <annevk>
roc: 👋

[13:25:09.0000] <roc>
ta

[14:18:38.0000] <jgraham>
roc: :(

[15:53:58.0000] <rniwa>
Domenic: nice PR!

[15:54:06.0000] <rniwa>
Domenic: looking through it and found a few typos and errors

[15:54:20.0000] <Domenic>
rniwa: awesome, happy to fix up :)

[15:54:46.0000] <Domenic>
I said no editorial stuff but what I really meant was "no multi-day back and forth waiting for LGTMs over editorial stuff"

[15:54:59.0000] <rniwa>
Domenic: yeah, let's not do that stuff

[15:55:19.0000] <rniwa>
Domenic: btw, i think there's one big bug in my original / your PR about HTML constructor

[15:55:27.0000] <rniwa>
Domenic: which is the way the global object is obtained

[15:55:36.0000] <rniwa>
or rather Document object

[15:55:48.0000] <Domenic>
rniwa: I tried to fix that by using current Realm's global, but I didn't think about it as hard as I should have, which is often necessary with "which global object" questions.

[15:55:54.0000] <rniwa>
Domenic: it's totally reasonable for you create your own document via DOMImplementation or get iframe.contentDocument

[15:56:09.0000] <rniwa>
Domenic: and extend that document's prototype

[15:56:37.0000] <rniwa>
Domenic: in that case, we don't want to end up looking up the registry of whatever script realm you happen to be running

[15:56:52.0000] <Domenic>
hmmmm

[15:56:54.0000] <rniwa>
Domenic: so instead of doing that, I think we should just get the global object out of the prototype or the constructor object

[15:57:11.0000] <rniwa>
Domenic: or the global object of [[Prototype]] internal slot of the constructor

[15:57:26.0000] <rniwa>
Domenic: the latter one in particular should always be in the right(™) document.

[15:58:00.0000] <Domenic>
Global out of the constructor function seems simplest

[15:58:07.0000] <rniwa>
Domenic: indeed

[15:58:23.0000] <rniwa>
Domenic: it's weird for your constructor to be extending another class in a different document anyways

[15:58:37.0000] <Domenic>
Yeah I'm trying to think if we can detect such mismatches and throw or something

[15:58:41.0000] <rniwa>
Domenic: but if we're going that rought, we may want to check that early in defineElement as well

[15:58:50.0000] <rniwa>
Domenic: so that author would catch it early

[15:58:50.0000] <Domenic>
right

[15:59:07.0000] <rniwa>
instead of your custom element never getting upgarded

[15:59:29.0000] <rniwa>
Domenic: oh wait, no

[15:59:49.0000] <rniwa>
Domenic: in the case you define class MyElement extends MyDocCreatedForHavingASeparateRegistry {}


2016-03-02
[16:00:06.0000] <rniwa>
Domenic: the constructor's realm in not in the same realm as MyDocCreatedForHavingASeparateRegistry

[16:00:17.0000] <rniwa>
Domenic: so I think you DO need to get the global object out of [[Prototype]] internal slot

[16:00:28.0000] <rniwa>
Domenic: if you cared about that use case that is

[16:00:34.0000] <Domenic>
I see!

[16:01:01.0000] <Domenic>
Hmm so we're inside HTMLElement already

[16:01:15.0000] <Domenic>
I wonder if we can get the realm/global object of the currently running function

[16:02:13.0000] <Domenic>
I guess you kind of can but that might be hard to implement?

[16:02:40.0000] <rniwa>
Domenic: oh I see

[16:02:47.0000] <rniwa>
Domenic: yeah you can probably just get the realm of the callee

[16:04:58.0000] <rniwa>
/me is getting uncomfortably familiar with JS these days...

[16:05:51.0000] <Domenic>
rniwa: https://github.com/w3c/webcomponents/commit/73ae047c90529546ad61ccc43cb995edf3bfb14f

[16:06:21.0000] <rniwa>
Domenic: do we need \ in [[\GlobalObject]] ?

[16:06:41.0000] <Domenic>
rniwa: yeah it's a ReSpec thing. Doesn't show up in the output

[16:07:14.0000] <rniwa>
I see

[16:08:56.0000] <rniwa>
Domenic: oh funny, we're not using upgrading for document.createElement?

[16:09:23.0000] <rniwa>
Domenic: (I like that)

[16:10:07.0000] <Domenic>
rniwa: hmmmm good question. I think it ended up being observably the same, and annevk wanted to use upgrading for uniformity, maybe? And I just forgot that?

[16:10:09.0000] <rniwa>
Domenic: your document.createElement is missing the case where we create HTMLUnknownElement.

[16:10:30.0000] <rniwa>
Domenic: no, it's still observable if you construct yourself inside a constructor before calling super

[16:10:33.0000] <Domenic>
I think that is covered by "Let interface be the element interface for localName and the HTML namespace" like it always was.

[16:10:51.0000] <rniwa>
oh I see

[16:11:09.0000] <Domenic>
Hmmmm. Well it seems pretty reasonable to not use upgrading there but I'll add a line comment for annevk to check it out.

[16:11:15.0000] <rniwa>
Domenic: here's a "better" proposal that makes this completely non-observable: http://lists.w3.org/Archives/Public/public-webapps/2016JanMar/0114.html

[16:11:39.0000] <rniwa>
Domenic: it adds an extra environmental record and an argument to `Construct`

[16:11:51.0000] <Domenic>
rniwa: yeah... I tried to get my head around that and it seemed pretty intrusive to the JS engine...

[16:11:55.0000] <rniwa>
Domenic: but that can do away with all the stack nonsensee so that's nice

[16:12:06.0000] <rniwa>
Domenic: indeed but it might be useful in the long term though

[16:12:41.0000] <rniwa>
Domenic: nonetheless, the difference manifests in such an edge case (and results in unexpected behavior) that we can probably change it in the future

[16:12:45.0000] <rniwa>
Domenic: if we wanted to

[16:12:57.0000] <rniwa>
Domenic: so I'm not too concerned even if we went with the stack approach at least in v1

[16:13:04.0000] <Domenic>
That's good to hear. Yeah, I'd be interested in trying to figure out a way to do that within existing ES spec constructs.

[16:13:19.0000] <rniwa>
Domenic: well, I think it's not too intrusive.

[16:13:29.0000] <Domenic>
I dunno an extra parameter to construct is pretty big

[16:13:34.0000] <Domenic>
Environment records are extensible though

[16:13:36.0000] <rniwa>
Domenic: the only problem is that it may not be too easy for each JS engine to support it

[16:13:46.0000] <rniwa>
Domenic: indeed, that's the biggest question for perf

[16:13:55.0000] <Domenic>
Yeah I tried to get ajklein to take a look at it but he hasn't had the time

[16:14:14.0000] <rniwa>
adding an extra argument in JS engine everywhere for this one edge case is such an over-engineering

[16:14:37.0000] <rniwa>
given the observable behavioral difference is so damn small

[16:14:51.0000] <rniwa>
having said that, it's a lot cleaner so I'll still put up for the future consideration

[16:15:13.0000] <Domenic>
👍

[16:15:36.0000] <rniwa>
Domenic: btw, you're missing one important thing in document.createElement

[16:15:44.0000] <rniwa>
Domenic: which is that you need to ensure whatever the constructor returned is indeed an Element

[16:15:59.0000] <rniwa>
Domenic: and probably best to return null or undefined or throw something in the case it isn't.

[16:16:41.0000] <Domenic>
rniwa: ah, great catch!

[16:16:58.0000] <Domenic>
The parser will also need that

[16:17:06.0000] <rniwa>
Domenic: yup

[16:17:11.0000] <rniwa>
Domenic: and create HTMLUnknownElement when it failed

[16:17:18.0000] <rniwa>
Domenic: since parser can't stop

[16:17:38.0000] <Domenic>
Yeah parser is going to be so much work :(

[16:18:11.0000] <rniwa>
Domenic: yup! I've been working on it for the last two weeks or so and boy, it's not fun.

[16:18:54.0000] <Domenic>
maybe you can spec it! i hear parsers in browsers follow the spec pretty closely...

[16:19:15.0000] <rniwa>
Domenic: it's actually not that much work in the spec.

[16:19:29.0000] <rniwa>
Domenic: it's more that our implementation of HTML5 parser isn't prepared to do these kinds of stuff

[16:20:31.0000] <Domenic>
hmm

[16:20:38.0000] <Domenic>
i just assume it'll require similar contortions to <script>.

[16:20:46.0000] <Domenic>
which is like most of the parsing spec

[16:20:55.0000] <rniwa>
Domenic: well, not really

[16:21:06.0000] <rniwa>
Domenic: the only reason we have to pause parser, etc... is because of the perf optimizations we have

[16:21:21.0000] <rniwa>
Domenic: and script has a bunch of legacy re-entrancy problems

[16:21:31.0000] <rniwa>
Domenic: but those things don't exist for custom elements (luckily)

[16:21:46.0000] <rniwa>
Domenic: but you're right that someone has to figure out how to update the spec...

[16:21:53.0000] <rniwa>
and make sure all details are covered

[16:24:23.0000] <rniwa>
Domenic: one more note: https://github.com/w3c/webcomponents/pull/405/files#r54660611

[16:24:38.0000] <Domenic>
thanks, saw that. gtg food, will pick this up later tonight or maybe tomorrow.

[16:24:57.0000] <rniwa>
Domenic: okay!

[16:25:06.0000] <rniwa>
Domenic: great work! thanks a lot for doing this!

[16:25:36.0000] <Domenic>
:D

[16:26:21.0000] <rniwa>
Domenic: btw, we just added the support for ::slotted

[16:26:32.0000] <rniwa>
Domenic: and I'm half way there on adding the parser support

[16:26:41.0000] <Domenic>
\o/

[16:26:45.0000] <rniwa>
Domenic: I'll let you guys know once the parser work is done because then you guys can play around with it

[16:26:50.0000] <rniwa>
ETA is like 1-2 weeks

[16:35:53.0000] <TabAtkins>
annevk: Heads-up, I spent today doing a lot of perf hacking, so you should see a *significant* decrease in built time.  I've been testing against real specs while doing this, so I shouldn't have regressed behavior anywhere, but let me know if you hit anything bad.

[16:36:11.0000] <nox>
Domenic: Shouldn't Document.all use elements' IDs (as in "An element can have an associated unique identifier (ID)") rather than the id attribute?

[16:37:03.0000] <Domenic>
nox: I don't think there's a difference? I didn't touch that text I believe

[16:37:12.0000] <nox>
Oh right.

[16:38:04.0000] <nox>
Domenic: Reviewed.

[16:38:28.0000] <Domenic>
nox: thanks, good catch

[16:38:46.0000] <nox>
How do you not kill your eyes reviewing that stuff all the time? :P

[17:12:52.0000] <JonathanNeal>
If Elements is a subclass of Array, should concat/map/sort/etc return a new Elements object or a new Array?

[17:19:06.0000] <rniwa>
JonathanNeal: a new Elements in ES2015

[17:19:53.0000] <Domenic>
although we might want to override map (and concat??) to return an Array instead

[17:20:12.0000] <Domenic>
the alternative is allowing Elements to contain non-elements and just ignore them when doing .query/.queryAll

[17:20:51.0000] <rniwa>
Is this Elements a new DOM/HTML interface we're adding?

[17:21:31.0000] <Domenic>
It's been in the spec for a while, but blocked on implementations supporting subclassing of Array. I guess that is probably not a blocker anymore.

[17:21:47.0000] <Domenic>
https://dom.spec.whatwg.org/#element-collections

[17:23:05.0000] <JonathanNeal>
I’m writing a polyfill. I’m hoping to match spec (best as one can).

[17:48:33.0000] <JonathanNeal>
Perhaps .concat is a bad thing to expect on Elements.

[17:51:02.0000] <JonathanNeal>
For instance, I would expect that queryAll('span').queryAll('span') on <span 1><span 2><span 3/></span></span> should only return [<span 2/>, <span 3/>] because I would expect it to sort the collections and remove duplicates. Is that a bad expectation?

[17:52:15.0000] <JonathanNeal>
And, if that is the case and .concat returns a new Elements collection, would it also sort and remove duplicates?

[17:54:21.0000] <JonathanNeal>
Domenic , TabAtkins, was this already worked out?

[22:20:46.0000] <annevk>
Domenic: rniwa: I was not against synchronous createElement. Maybe someone else? Don't think it matters much. Did you make the code reusable for the parser?

[22:21:39.0000] <annevk>
JonathanNeal: seems reasonable

[22:22:06.0000] <rniwa>
annevk: it is, other than the fact we need to swallow the exception and create a HTMLUnknownElement instead

[22:23:10.0000] <annevk>
Right, you do different things with the result

[00:19:31.0000] <MikeSmith>
zcorpan: they way you fixed the square-brackets problem with https://github.com/whatwg/wattsi/pull/23 is very nice

[00:20:00.0000] <zcorpan>
MikeSmith: thanks

[00:20:33.0000] <zcorpan>
Hixie_: want to have a quick look at the PR ^ ?

[00:21:01.0000] <MikeSmith>
it may seem obvious but to me at least it wasn’t, because when I saw that issue my first thought was instead, shit now I have to write a percent-encoder

[00:22:21.0000] <MikeSmith>
I had seen that MungeTopicToID function in the code but hadn’t bothered to pay attention to it

[00:22:27.0000] <MikeSmith>
lesson learned

[00:23:43.0000] <MikeSmith>
but glad you go to that before me, because I probably would have burned up time trying to write a percent-encoder and then ended up realizing that was not the right way

[02:04:52.0000] <Ms2ger>
Oh look, glazou found the webkit* events in the DOM spec

[02:06:19.0000] <annevk>
No fault in that reaction

[02:06:33.0000] <annevk>
Hopefully he recovers before noticing webkitMatchesSelector

[02:09:50.0000] <jgraham>
I think he will find it hard to read specs whilst passed out

[03:39:12.0000] <MikeSmith>
haha

[03:52:13.0000] <nox>
Ms2ger: Where is that?

[03:52:54.0000] <Ms2ger>
https://twitter.com/glazou

[03:53:23.0000] <nox>
Ah ah.

[03:53:32.0000] <Ms2ger>
annevk, btw https://twitter.com/glazou/status/700321457734356992

[03:56:15.0000] <Ms2ger>
annevk, what should new Blob(undefined) do?

[03:56:28.0000] <annevk>
Ms2ger: it's ugly, but don't really have the same reaction to it as I used to

[03:57:16.0000] <annevk>
Ms2ger: hmm, throw?

[03:57:27.0000] <annevk>
Ms2ger: iirc that's equivalent to new Blob(), which throws

[03:57:36.0000] <Ms2ger>
new Blob() doesn't throw

[03:57:50.0000] <annevk>
oh right, well it should do that then

[03:58:06.0000] <Ms2ger>
Actually, (undefined) does throw :)

[03:58:13.0000] <annevk>
I don't understand why the first argument is not simply marked as optional

[03:58:29.0000] <annevk>
If I had time I'd clean up File API

[03:58:40.0000] <Ms2ger>
If the spec did use `optional`, you would have been right

[04:00:06.0000] <Ms2ger>
/me files an issue on webidl (sorry bz)

[04:00:23.0000] <nox>
Why sorry?

[04:00:41.0000] <annevk>
Ms2ger: the spec should use optional

[04:00:53.0000] <annevk>
Ms2ger: or is there some compat thing?

[04:01:20.0000] <Ms2ger>
I don't think so

[04:02:02.0000] <nox>
So passing undefined == omitting an optional parameter?

[04:02:13.0000] <annevk>
nox: yes

[04:02:14.0000] <Ms2ger>
But it's weird that the current code is not equivalent to `optional`

[04:03:18.0000] <nox>
An ECMAScript value V is converted to an IDL sequence<T> value as follows:

[04:03:19.0000] <nox>
If V is not an object, throw a TypeError.Ms2ger: Does it say that for sequence<T>, undefined == empty sequence?

[04:03:28.0000] <nox>
I can't copy-paste.

[04:03:29.0000] <Ms2ger>
https://heycam.github.io/webidl/#es-overloads

[04:03:29.0000] <annevk>
Ms2ger: nah, that's because of XMLHttpRequest

[04:03:36.0000] <nox>
"An ECMAScript value V is converted to an IDL sequence<T> value as follows: If V is not an object, throw a TypeError."

[04:03:40.0000] <annevk>
Ms2ger: search for "Unfortunately legacy content prevents treating the async argument being undefined identical from it being omitted."

[04:03:40.0000] <nox>
undefined isn't an object, right?

[04:04:02.0000] <Ms2ger>
nox, that happens before we get to "An ECMAScript value V is converted to an IDL sequence<T> value as follows"

[04:04:07.0000] <Ms2ger>
annevk, hmm

[04:04:21.0000] <annevk>
Ms2ger: so this seems like a File API issue

[04:04:32.0000] <nox>
I see, and the second argument is optional.

[04:04:39.0000] <annevk>
Ms2ger: unless you can figure out a way to make the File API IDL work while not breaking the XMLHttpRequest IDL...

[04:04:52.0000] <nox>
Ms2ger: But why would omitting a sequence argument be like the empty sequence?

[04:05:00.0000] <annevk>
(it does not seem ideal though, since it's rather magical)

[04:05:22.0000] <Ms2ger>
nox, it isn't

[04:05:51.0000] <nox>
Ah, I thought that's what you meant by "But it's weird that the current code is not equivalent to `optional`".

[04:06:31.0000] <Ms2ger>
https://github.com/w3c/FileAPI/issues/33

[04:15:24.0000] <MikeSmith>
JakeA: http://stackoverflow.com/questions/35711724/progress-indicators-for-fetch

[04:15:47.0000] <MikeSmith>
annevk: ⬆

[04:16:15.0000] <MikeSmith>
「How would I write "a pass-through stream to monitor the bytes" sent?」

[04:16:40.0000] <JakeA>
MikeSmith: will answer. We're waiting to see how streams pan out there, if not we'll have to find another way to manage progress

[04:17:01.0000] <JakeA>
There's a lot of weirdness here due to how uploads interact with redirects

[04:17:29.0000] <annevk>
Quite

[04:25:25.0000] <JakeA>
MikeSmith: http://stackoverflow.com/a/35747208/123395

[04:26:10.0000] <MikeSmith>
JakeA: superーthanks

[05:13:22.0000] <ondras>
annevk: do I understand correctly that a cross-origin XHR with a custom Accept header must not be redirected (302)?

[05:21:24.0000] <Domenic>
I have a basic question about legacy single-byte encodings. What are the columns in https://encoding.spec.whatwg.org/index-windows-1252.txt ?

[05:23:30.0000] <ondras>
single-byte value, code point, unicode visualisation, description ?

[05:23:45.0000] <Domenic>
but what does this single-byte value actually represent

[05:24:05.0000] <Domenic>
it seems like there's a + 0x80 step?

[05:25:06.0000] <ondras>
apparently, as one-byte encodings differ only in 127-255 values?

[05:25:13.0000] <Domenic>
hmmm

[05:25:25.0000] <Domenic>
right ok

[05:28:30.0000] <ondras>
*128-255

[05:43:45.0000] <Domenic>
Is there a name for the single-byte encoding that just encodes things as their equivalent unicode?

[05:43:59.0000] <Domenic>
So the byte 0x8B just goes to U+008B PARTIAL LINE DOWN

[05:44:17.0000] <Domenic>
I can't find any index table with that

[05:44:46.0000] <ondras>
well such encoding would have to be pre-dated by unicode, right?

[05:45:31.0000] <Domenic>
heh, yeah, i guess so

[05:45:34.0000] <Domenic>
V8 comes with one built in

[05:46:33.0000] <nox>
So UTF-8 but with lone code units interpreted as Latin-1? Or something like that?

[05:46:40.0000] <nox>
Domenic: ^

[05:46:47.0000] <nox>
(Just curious about what you mean.)

[05:47:07.0000] <nox>
Or do you just mean Latin-1? oO

[05:48:25.0000] <ondras>
hmmh, https://en.wikipedia.org/wiki/Latin-1_Supplement_%28Unicode_block%29 ?

[05:49:42.0000] <nox>
Code point wise, Unicode is a superset of Latin-1, so maybe that's what you meant?

[05:53:02.0000] <Domenic>
nox: I don't think that's true. For 128-159, they mismatch

[05:53:12.0000] <Domenic>
nox: according to https://encoding.spec.whatwg.org/index-windows-1252.txt at least

[05:54:06.0000] <nox>
Domenic: https://en.wikipedia.org/wiki/ISO/IEC_8859#Relationship_to_Unicode_and_the_UCS

[05:54:08.0000] <Domenic>
e.g. 0x8B in latin1 is U+2039 ‹ (SINGLE LEFT-POINTING ANGLE QUOTATION MARK)

[05:54:17.0000] <nox>
Domenic: That is ISO 8859-1 no?

[05:54:49.0000] <Domenic>
nox: according to the Encoding Standard latin1 === windows-1252 === iso-8859-1, in browsers

[05:56:21.0000] <Domenic>
Whereas http://www.open-std.org/JTC1/SC2/WG3/docs/n411.pdf for ISO 8859-1 just fails to define what happens in the range 0-159

[05:56:47.0000] <Domenic>
*128-159

[06:03:15.0000] <annevk>
ondras: not per browsers, works per spec now

[06:03:18.0000] <gsnedders>
https://en.wikipedia.org/wiki/C0_and_C1_control_codes is a decent summary of C1 stuff

[06:05:23.0000] <annevk>
Domenic: working of tables is defined in spec, mostly a pointer to code point mapping

[06:05:39.0000] <Domenic>
annevk: yeah just got thrown off by the +/0 0x80

[06:05:41.0000] <Domenic>
+/-

[06:08:34.0000] <nox>
Domenic: This is really confusing.

[06:09:55.0000] <nox>
Domenic: I think the Encoding Standard redefined that.

[06:10:03.0000] <ondras>
annevk: I am confused. The spec says that such redir is an error, no?

[06:10:26.0000] <ondras>
If the response has an HTTP status code of 301, 302, 303, 307, or 308

[06:10:26.0000] <ondras>
Apply the cache and network error steps.

[06:10:33.0000] <Domenic>
nox: I think the Encoding Standard defined what browsers already do with meta charset="iso-8859-1" or the UI switcher toggling to iso-8859-1

[06:10:55.0000] <Domenic>
browsers don't have the luxury of saying "welp, you used something between 128-159 which the spec doesn't define; better crash your page!

[06:11:24.0000] <nox>
Domenic: Sure but what is the Latin 1 in https://en.wikipedia.org/wiki/Latin-1_Supplement_%28Unicode_block%29#Latin-1_punctuation_and_symbols?

[06:12:52.0000] <nox>
Ah there is an explanation in https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Coverage

[06:14:01.0000] <nox>
'ISO-8859-1 is (according to the standards at least) the default encoding of documents delivered via HTTP with a MIME type beginning with "text/" (however the HTML5 specification requires that documents advertised as ISO-8859-1 actually be parsed with the Windows-1252 encoding.[4])'

[06:14:15.0000] <annevk>
ondras: what spec?

[06:14:31.0000] <nox>
Domenic: So the name you are looking for is IANA ISO-8859-1

[06:14:48.0000] <nox>
Domenic: Not HTML5 ISO-8859-1, nor ISO's ISO 8859-1.

[06:15:16.0000] <nox>
Erlang uses IANA ISO-8859-1. That's where I got the "it is a subset of Unicode".

[06:15:21.0000] <Ms2ger>
Can someone check http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3933 on Edge?

[06:15:22.0000] <Ms2ger>
annevk?

[06:15:48.0000] <nox>
Domenic: Are you satisfied by that answer?

[06:21:28.0000] <nox>
Or not.

[06:21:36.0000] <nox>
/me gives up, too many similar names everywhere.

[06:22:17.0000] <ondras>
annevk: https://www.w3.org/TR/cors/

[06:28:47.0000] <gsnedders>
nox: browsers used ISO-8859-1 as Windows-1252 since forever ago. AFAIK IE always has, and I /think/ Netscape always has too.

[06:29:08.0000] <nox>
gsnedders: Yeah but then I would like to know where Erlang's definition comes from. :)

[06:29:30.0000] <nox>
But I got ISOitis and stopped looking for it.

[06:33:45.0000] <Ms2ger>
gsnedders, you don't have Edge?

[06:46:50.0000] <gsnedders>
Ms2ger: It's failing to auto-update to the latest version :\

[06:47:40.0000] <Domenic>
Summarized encoding situation at https://github.com/nodejs/node/pull/5504#issuecomment-191266052

[06:50:12.0000] <gsnedders>
nox: Erlang's definition came from ISO-8859-1 and ECMA-48 (IIRC), and is what most things outside of the web use the "iso-8859-1" label to mean. (Note the "latin1" label has a lot more variation)

[06:51:12.0000] <Ms2ger>
Still looking for someone who'll admit to having Edge around

[06:51:58.0000] <jgraham>
Ms2ger: https://dev.windows.com/en-us/microsoft-edge/tools/vms/linux/

[06:52:11.0000] <Ms2ger>
Thank you, mr helpful

[06:52:17.0000] <Ms2ger>
You got one of those?

[06:52:49.0000] <nox>
gsnedders: Takk.

[06:52:59.0000] <jgraham>
Ms2ger: No, but you could have

[07:13:57.0000] <gsnedders>
Ms2ger: so yeah, I have Edge 20, and it claims there are no updates available.

[07:31:45.0000] <annevk>
Ms2ger: still no Edge

[07:31:56.0000] <annevk>
ondras: that's not the standard you're looking for

[07:32:04.0000] <annevk>
ondras: https://fetch.spec.whatwg.org/

[07:34:38.0000] <ondras>
annevk: thanks, hmm, CORS specced within the fetch spec?

[07:34:55.0000] <ondras>
annevk: I am going to use XHR for this...

[07:37:28.0000] <annevk>
ondras: XHR sits atop Fetch

[07:38:33.0000] <ondras>
/me honestly confused by the rich list of 5.x chapters under "fetching"

[07:38:41.0000] <ondras>
now where does my question fit into this

[07:39:28.0000] <ondras>
http-redirect-fetch probably

[07:39:42.0000] <annevk>
ondras: step 4 of https://fetch.spec.whatwg.org/#http-fetch basically

[07:41:19.0000] <ondras>
I would say step 5 with

[07:41:20.0000] <ondras>
redirect status

[07:41:32.0000] <ondras>
but anyway, according to this spec, it should work

[07:41:33.0000] <ondras>
thanks

[07:41:45.0000] <ondras>
also, custom request headers are to be persisted across redirections, right?

[07:48:36.0000] <annevk>
ondras: yes

[07:48:43.0000] <annevk>
ondras: that should be very clear from the algorithm

[07:51:15.0000] <ondras>
fine fine, thanks for assistance

[08:37:00.0000] <miketaylr>
can we change the topic to "this entire API is a mysterious clusterfuck of legacy garbage"

[08:42:19.0000] <gsnedders>
that seems reasonable to me

[08:49:20.0000] <annevk>
Domenic: I was just told by baku why awb was correct

[08:50:03.0000] <annevk>
Domenic: MessageChannel has a queue, and the target MessagePort can switch realms before messages are actually delivered (when you invoke start())

[08:50:19.0000] <annevk>
Domenic: so if you want to properly account for that, you need to serialize and deserialize

[08:50:25.0000] <Domenic>
annevk: makes sense

[08:50:56.0000] <annevk>
Domenic: and if SAB indeed wants varying behavior based on realm, we'd have to go there...

[09:08:05.0000] <annevk>
I feel sad now that I didn't know that ahead of time, oh well, SAB can wait a bit

[09:48:06.0000] <Domenic>
document.all is the worst. custom bindings are the worst.

[09:48:25.0000] <Domenic>
having to write test cases for elements with ids like "Infinity" "0x0", and "+0" is the worst.

[09:48:37.0000] <miketaylr>
haha

[12:26:48.0000] <annevk>
Domenic: will you get to https://github.com/whatwg/html/pull/783 today? It's not that big

[12:27:02.0000] <Domenic>
annevk: literally just clicked on that email

[12:27:06.0000] <annevk>
Domenic: and fixes the last "regression"

[12:27:09.0000] <annevk>
I see

[12:28:23.0000] <Domenic>
(as in, clicked on the email that i earlier flagged, as now i am reviewing it)

[12:32:02.0000] <annevk>
Domenic: I'm somewhat glad I accidentally discovered that even ordinary objects have internal slots

[12:32:24.0000] <annevk>
Domenic: which I kinda knew, but not actively, if that makes sense

[12:33:11.0000] <Domenic>
yeah that surprised me a bit

[12:37:10.0000] <annevk>
I thought https://twitter.com/glazou/status/705089928238125056 was advice from CSS

[12:38:19.0000] <annevk>
Is this the grownup version of the kid saying the other parent endorsed some plan?

[12:40:05.0000] <Domenic>
yep

[12:40:16.0000] <Domenic>
this is literally not a whatwg decision

[12:40:20.0000] <Domenic>
this is a tab and fantasai decision

[12:44:18.0000] <jsbell>
when you find out someone is using your polyfill via npm and you made an API-breaking change and forgot to bump the minor version

[12:46:49.0000] <annevk>
Domenic: https://twitter.com/rillian/status/705109214885126144 is relevant to your interests

[12:56:50.0000] <Domenic>
lol i just switched to win64 yesterday

[12:59:34.0000] <annevk>
hah

[13:02:54.0000] <TabAtkins>
annevk: Don't worry, glazou just got angry about the decision on the call today.

[13:03:53.0000] <TabAtkins>
(His entire argument is that the name "list-item" makes it seem a little confusing to apply to <summary>, which isn't a list item.  He wasn't impressed by the reply that 'display' has no semantic value.)


2016-03-03
[16:30:08.0000] <MikeSmith>
jsbell: So, we really need a new, active editor for the File API spec

[16:30:55.0000] <MikeSmith>
we've got open bugs and of course other specs depending on it

[16:31:41.0000] <MikeSmith>
hoping you might be able to help surface a new editor for it

[16:32:41.0000] <MikeSmith>
maybe in consultation with slightlyoff

[16:33:23.0000] <MikeSmith>
however y'all make the magic

[16:48:02.0000] <jsbell>
MikeSmith: I'll see what we can wrangle.

[16:56:16.0000] <rniwa>
can someone review my PR request for template element test? https://github.com/w3c/web-platform-tests/pull/2651

[16:59:27.0000] <jsbell>
MikeSmith: out of curiosity, is the current spec hand-authored as it appears (i.e. not respec/bs, etc) ?

[17:00:01.0000] <jsbell>
kinda looks like respec output...

[17:30:29.0000] <TabAtkins>
jsbell: I pushed a bikeshedded version a while ago.

[17:31:43.0000] <TabAtkins>
jsbell: There's a PR open that hasn't  been merged yet for it. :/

[18:13:58.0000] <Domenic>
Just two days of custom elements spec work and I am immensely sick of Respec's flash-of-losing-my-scroll-position

[19:35:55.0000] <rniwa>
Domenic: yt?

[19:35:59.0000] <rniwa>
annevk: yt?

[19:36:05.0000] <Domenic>
rniwa: yep

[19:36:07.0000] <rniwa>
Domenic: hi

[19:36:21.0000] <rniwa>
Domenic: we have one "minor" problem with regards to finding the right registry

[19:36:36.0000] <rniwa>
Domenic: when you create a document via DOMImplementation

[19:36:54.0000] <Domenic>
hmmmm

[19:36:57.0000] <rniwa>
Domenic: and author calls defineElement on it

[19:37:06.0000] <rniwa>
Domenic: and HTMLElement's constructor is called in super()

[19:37:19.0000] <rniwa>
Domenic: the global object isn't associated with THAT document

[19:37:20.0000] <Domenic>
yeah

[19:37:23.0000] <Domenic>
that is broken

[19:37:53.0000] <Domenic>
ok

[19:38:01.0000] <Domenic>
so i think each registration needs to store its document too?

[19:38:07.0000] <Domenic>
wait no that doesn't work

[19:38:16.0000] <Domenic>
hmm maybe not best to think about this at the end of a long day

[19:38:22.0000] <Domenic>
File the issue and we'll figure it out tomorrow?

[19:38:33.0000] <Domenic>
This is tricky...

[19:39:01.0000] <Domenic>
I am not sure it is solvable

[19:39:26.0000] <Domenic>
for the new CustomElement() case there's just no way to know

[19:43:06.0000] <rniwa>
Domenic: indeed.

[19:45:34.0000] <Domenic>
this seems like a more general problem with non-1:1 document:windows

[19:45:43.0000] <pwf>
hello! is there a transform implemented in any major browser that would let me stream lines from a web request?

[19:45:49.0000] <Domenic>
which I guess includes 1-window-2-documents for initial about:blank navigation

[19:45:53.0000] <rniwa>
Domenic: we don't even know what to do with document.createElement either

[19:46:02.0000] <Domenic>
and 1-document-several-windows for document.open()

[19:46:11.0000] <rniwa>
Domenic: since you can create yourself with another document before calling super()

[19:46:18.0000] <pwf>
the streams spec looks like exactly what i want, but i don't know who's implemented the bits i want (or if there are any examples of it...)

[19:47:15.0000] <Domenic>
pwf: Chrome has implemented streaming bodies. https://googlechrome.github.io/samples/fetch-api/fetch-response-stream.html https://jakearchibald.com/2016/streams-ftw/

[19:47:30.0000] <Domenic>
rniwa: sure, but that's one of those "don't do that" scenarios I guess

[19:47:30.0000] <pwf>
that's the article that led me here haha

[19:47:46.0000] <rniwa>
Domenic: well, the problem is that people WILL do it

[19:47:52.0000] <rniwa>
Domenic: and we have to define the behavior

[19:47:57.0000] <Domenic>
right, certainly

[19:48:01.0000] <Domenic>
it just might do something weird

[19:48:01.0000] <pwf>
oh wait, the 2015 one did! i haven't seen the 2016 one, thank you!

[19:48:04.0000] <Domenic>
and i'm ok with that

[19:48:35.0000] <Domenic>
new CustomElement() not working seems bad though

[19:48:36.0000] <rniwa>
Domenic: so I think we need to create in the global object's document and adopt it

[19:48:48.0000] <Domenic>
i see

[19:48:55.0000] <rniwa>
Domenic: it's okay to do this because all prototype objects, etc... are the same

[19:49:20.0000] <rniwa>
Domenic: there is no issue of identify (e.g. misleading instanceof behavior)

[19:49:39.0000] <Domenic>
i dunno i am starting to feel we should go back to not allowing implementation.createHTMLDocument()?

[19:50:00.0000] <rniwa>
Domenic: well, we need to solve this problem regardless if we ever wanted to allow custom registry

[19:50:06.0000] <pwf>
is there a list of the decoders/pipes already built into chrome Domenic? like one that grabs lines for me maybe?

[19:50:17.0000] <Domenic>
pwf: nothing is built-in; you write your own

[19:50:30.0000] <Domenic>
i guess we could make it work but it seems bad that you do doc.defineElement("x-foo", CE) and then new CE() always fails

[19:52:23.0000] <rniwa>
Domenic: no, CE() will work in that case

[19:52:29.0000] <rniwa>
new CE()*

[19:52:40.0000] <Domenic>
here doc = document.implementation.createHTMLDocument(). How will it work?

[19:53:00.0000] <rniwa>
Domenic: we just need not to throw TypeError in steps 3 and 4 of HTMLElement constructor

[19:53:11.0000] <rniwa>
Domenic: basically allow any constructor to call HTMLElement's constructor

[19:53:22.0000] <Domenic>
hmmmm

[19:53:24.0000] <rniwa>
Domenic: as long as its [[Prototype]] eventually leads to HTMLElement

[19:53:35.0000] <rniwa>
its=new.target

[19:54:01.0000] <rniwa>
Domenic: this would mean that you can do new (class extends HTMLElement{})

[19:54:07.0000] <rniwa>
Domenic: without ever calling defineElement though...

[19:54:15.0000] <Domenic>
yeah what would that even give you

[19:54:19.0000] <Domenic>
what is its tagname etc.

[19:54:20.0000] <rniwa>
oh wait...

[19:54:23.0000] <rniwa>
yeah, :(

[19:54:28.0000] <rniwa>
we don't know the tag name

[19:54:44.0000] <Domenic>
if we had a real HTMLElement constructor this would be solvable

[19:55:13.0000] <rniwa>
Domenic: actually, this was the reason my HTMLElement constructor took the tagname as an argument

[19:55:14.0000] <Domenic>
https://github.com/domenic/element-constructors/blob/master/element-constructors.js#L113

[19:55:37.0000] <rniwa>
Domenic: but even if you did, it still woudln't work because you can't verify whether that tagname is associated with the particular interface or not

[19:55:44.0000] <Domenic>
delegates to https://github.com/domenic/element-constructors/blob/master/element-constructors.js#L31

[19:55:57.0000] <rniwa>
Domenic: in particular, it's possible for super() call to be made with a "wrong" new.target

[19:55:59.0000] <Domenic>
it needs a document argument too

[19:56:04.0000] <rniwa>
Domenic: and there will be no way of knowing that

[19:56:44.0000] <rniwa>
Domenic: I think the easiest thing to do will be accepting an optional document argument in HTMLElement's constructor

[19:57:03.0000] <rniwa>
Domenic: and make Construct call pass in the document

[19:57:11.0000] <rniwa>
Domenic: so that in common case, author can omit it

[19:57:35.0000] <Domenic>
rniwa: do you actually expect authors to write super({ document: some particular document }) though?

[19:57:35.0000] <rniwa>
Domenic: but if they wanted to, they can pass along document to support window-less document to create their own registry

[19:57:48.0000] <rniwa>
Domenic: ugh... it's not do another dictionary

[19:57:51.0000] <Domenic>
hmm hmm

[19:57:52.0000] <rniwa>
Domenic: lets*

[19:58:00.0000] <rniwa>
Domenic: no, I'd expect authors to write

[19:58:05.0000] <Domenic>
no please let's there's so many params, they need names

[19:58:08.0000] <rniwa>
constructors(...args) { super(...args); ... }

[19:58:18.0000] <Domenic>
i see

[19:58:32.0000] <rniwa>
Domenic: I really don't want to use Dictionary here

[19:58:37.0000] <Domenic>
why?

[19:58:49.0000] <rniwa>
Domenic: if anything, we should create an opaque object authors can't mess with it

[19:58:49.0000] <Domenic>
this is classic dictionary stuff. a bunch of optional options.

[19:58:51.0000] <rniwa>
Domenic: performance

[19:59:04.0000] <Domenic>
make a fast path for undefined?

[19:59:08.0000] <rniwa>
Domenic: no, I'd make them required if anything

[19:59:19.0000] <Domenic>
that might be better

[19:59:20.0000] <rniwa>
Domenic: I'd be strongly opposed to making this dictionary

[19:59:35.0000] <Domenic>
rniwa: well i'd be strongly opposed to it not being a dictionary

[19:59:45.0000] <rniwa>
Domenic: okay, so no argument to super()

[19:59:48.0000] <rniwa>
Domenic: let

[19:59:57.0000] <rniwa>
let's not support multiple registries per window

[20:00:46.0000] <Domenic>
SGTM :D

[20:03:50.0000] <rniwa>
Domenic: a funny thing is, the spec currently says that already LOL

[20:04:02.0000] <rniwa>
Domenic: https://w3c.github.io/webcomponents/spec/custom/#creating-and-passing-registries

[20:04:40.0000] <Domenic>
rniwa: haha right, i guess so.

[20:08:32.0000] <pwf>
what's the buffer size on reader.read(),then(some_function)? i plan on abusing it like i would a websocket only without messing with websockets

[20:08:54.0000] <pwf>
in my testing it seems like i can just ignore the fact that a 'message'/'chunk'/whatever will end halfway through

[20:11:33.0000] <rniwa>
Domenic: document.open replaces the global object!?

[20:12:07.0000] <rniwa>
Domenic: or did you mean window.open?

[20:15:50.0000] <Domenic>
rniwa: nope, document.open

[20:16:31.0000] <Domenic>
rniwa: it kind of tears down the document, then creates a new window, and sets that window's document to the document being document.open()ed

[20:16:44.0000] <Domenic>
https://html.spec.whatwg.org/#dom-document-open

[20:17:05.0000] <pwf>
ok it turns out ignoring buffer size on read did indeed bite me...

[20:17:25.0000] <Domenic>
pwf: the buffer size is "however many bytes network conditions dictate". You shouldn't rely on it.

[20:18:12.0000] <pwf>
{"image": "images/test_50.png", "iteration": "50"}

[20:18:12.0000] <pwf>
poop.html:15 Uncaught (in promise) SyntaxError: Unexpected token o

[20:18:18.0000] <pwf>
errr... ignore my filename

[20:19:07.0000] <pwf>
why did console.log get a full json object but i couldn't decode it?

[20:22:50.0000] <pwf>
ohh... i'm using result instead of the return value of decoder.decode

[22:12:55.0000] <rniwa>
Domenic: it seems that the corollary of that discussion is that we also need to disallow defineElement on template.content

[22:13:03.0000] <rniwa>
Domenic: because we're going to face the same issue

[22:19:52.0000] <annevk>
rniwa: yeah, that's a different document too so falls out naturally

[22:20:56.0000] <annevk>
rniwa: this was bz's concern with new Text and such, there we simply pick a document from a global

[22:21:14.0000] <rniwa>
annevk: yeah, now I remember that discussion

[22:21:25.0000] <rniwa>
annevk: it's funny how we keep re-discovering the same problem :(

[22:21:42.0000] <rniwa>
one of these days, i'm gonna improve my long term memory...

[22:22:26.0000] <annevk>
rniwa: I'm surprised actually that it took until now for this to become really clear

[22:23:04.0000] <annevk>
rniwa: should have been clear to custom elements folks long ago I'd think and documented

[22:24:30.0000] <rniwa>
annevk: I think the problem is that people who worked on v0 aren't actively participating in this discussion

[22:52:42.0000] <annevk>
Seems likely, but v0 never worked this through either I think

[00:05:02.0000] <annevk>
Oh yes, someone else is removing CanvasProxy \o/

[01:04:03.0000] <zcorpan>
gah someone please fix svg favicons, i can't find the html standard among my open tabs anymore :-(

[01:21:55.0000] <annevk>
/me wonders if he can convince someone else to review some new URL tests

[01:22:05.0000] <annevk>
zcorpan: use Firefox?

[01:23:01.0000] <zcorpan>
annevk: yeah, or I could use Opera 12 :-)

[01:23:56.0000] <annevk>
zcorpan: I see you value your security

[01:26:33.0000] <zcorpan>
yep, i use passwords that are hard to remember!

[01:26:59.0000] <zcorpan>
(true story)

[03:14:11.0000] <hgl>
what do you guys think about the react trend? i feel like it's trying to hide people from DOM. with react, every change to DOM should go through the vdom. i don't think every kind of ui can be expressed by vdom, and it's pretty awkward too when it comes to animations. why browsers can't offer a declarative api and figure our the minimal dom change? i think that's the core value of react.

[03:15:51.0000] <annevk>
hgl: it's not that simply, unfortunately

[03:16:30.0000] <hgl>
annevk: care to explain some details? tree comparison is too expensive for browsers to do?

[03:17:01.0000] <annevk>
hgl: the diffing is not really the important thing

[03:17:18.0000] <annevk>
hgl: the important thing is that react uses DOM as a render step

[03:17:39.0000] <annevk>
hgl: so they only change the DOM when they want to render

[03:18:30.0000] <annevk>
hgl: providing more control over when rendering happens, or maybe having some kind of batching thing for DOM mutations, might help, but it's tricky to unravel all that

[03:21:27.0000] <hgl>
annevk, i don't quite understand what you mean by using DOM as a render step? if node provide an api like, node.render(template), where template is the template element containing the final node structure and browser will figure out the minimal steps to render the children of node, and people only call it when they want to "render", isn't it the same thing as react?

[03:24:07.0000] <annevk>
I don't see how that would solve any of the problems

[03:24:24.0000] <annevk>
Unless you don't care about the DOM as the source of truth

[03:26:42.0000] <hgl>
maybe i didn't look at react/dom from a right angle, but for me, the advantage of react is i don't have to do the imperative steps to bring DOM to a structure i want. with react, i just tell it the structure i want, and it'll figure all the imperative steps for me. i thoughts this tedious process was that react tried to solve?

[03:27:47.0000] <hgl>
(being a non-native speaker, i miss the ability to edit my messages in slack :)

[03:32:38.0000] <hgl>
put it another way, i see react as a mapping engine that maps data to dom structure. i specify the mapping, and give it the data, i get correct dom structure out.

[03:32:49.0000] <annevk>
The problem with not treating the DOM as the source of truth but some parallel object model is that any references to DOM objects get destroyed, updates to DOM objects might get lost, state in DOM objects might get lost, etc.

[03:33:59.0000] <annevk>
There's this mantra around react that updating DOM is expensive, but what's expensive is layout, not the DOM, that's just a data structure

[03:35:04.0000] <hgl>
yeah, that's exactly why i want browsers to have such api, so they can use real DOM as the "parallel object model", i hate this parallel object model (vdom) from react...

[03:36:07.0000] <nox>
How would that API work?

[03:36:17.0000] <nox>
What is 'template'?

[03:36:29.0000] <hgl>
because i can no longer touch dom myself... all changes i want to make, i need to go though this parallel object

[03:36:43.0000] <nox>
How do you enforce you didn't touch DOM yourself?

[03:36:59.0000] <hgl>
umm, something like <template><div></div></template>?

[03:37:12.0000] <nox>
That's still DOM?

[03:37:49.0000] <hgl>
yes, like your put this string in html, ask browsers to turn it into dom, then pass the template element to node.render(template)

[03:38:25.0000] <hgl>
the point of making browsers to have this API, is that i hope i can mix and match declarative & imperative ways to manipulate DOM

[03:38:49.0000] <nox>
I don't get the advantage over just using the DOM in that template.

[03:41:18.0000] <nox>
 annevk: Mmmh, I'm confused, is "replace all with node within a parent" actually bound to any DOM method?

[03:41:36.0000] <annevk>
nox: innerHTML

[03:41:43.0000] <nox>
annevk: Ah.

[03:41:45.0000] <annevk>
nox: textContent

[03:41:59.0000] <nox>
annevk: Was looking for innerHTML.

[03:42:09.0000] <nox>
annevk: Couldn't find a case in the DOM spec where the DocumentFragment case was used.

[03:42:10.0000] <annevk>
nox: innerHTML is the DocumentFragment case

[03:42:13.0000] <annevk>
heh

[03:42:14.0000] <nox>
:)

[03:42:27.0000] <hgl>
nox, oh, do you mean i should just do node.textContent = ''; node.appendChild(template.childNode[0])?

[03:42:45.0000] <nox>
annevk: Was wondering if hgl would be satistfied by a node.replaceAllChildren(template.cloneNode(true)).

[03:42:57.0000] <nox>
Well, not template, but the document fragment inside.

[03:43:21.0000] <nox>
hgl: Anyway, I don't see what your proposal avoids.

[03:43:38.0000] <nox>
It's still the DOM, you can still access it in many ways, etc.

[03:44:42.0000] <hgl>
i see what you mean...

[03:44:49.0000] <hgl>
maybe i should put it this way

[03:45:34.0000] <hgl>
i'd like template element to let me insert data declaratively... <template><div>{obj.prop}</div></template>

[03:46:02.0000] <nox>
Sounds like you want slots and things like that.

[03:46:21.0000] <hgl>
currently if you want a template to contain data, the imperative steps to fill it can be huge

[03:46:39.0000] <hgl>
wow, slots? it already supports something like that?

[03:46:45.0000] <nox>
hgl: https://webkit.org/blog/4096/introducing-shadow-dom-api/

[03:46:46.0000] <hgl>
does a spec exist?

[03:47:14.0000] <nox>
No idea what the status of this is, I'm a newcomer around here.

[03:48:06.0000] <annevk>
It's at the point where we've done the first 80% and are now figuring out the remaining 80%

[03:48:34.0000] <hgl>
first 80% and remaining 80%..... what happened...

[03:53:25.0000] <hgl>
nox, annevk, slots look like what i wanted, very cool, thank for letting me know...

[03:59:20.0000] <annevk>
JakeA: https://twitter.com/jaffathecake/status/705355715414781953 is pretty compelling

[04:00:00.0000] <JakeA>
agreed, as more elements are added to that demo, Servo hits a JS bottleneck way before paint

[04:01:19.0000] <jgraham>
Yeah, the main problem with servo is the sheer amount of junk you need to make a web browser these days

[04:01:21.0000] <JakeA>
With Chrome's GPU renderer (which isn't the one I used in the recording), its GPU stuff is the bottle neck. Lack of batching I think.

[04:01:21.0000] <annevk>
It's about time layout get its "order of magnitude" improvement now JavaScript has had several of those

[04:01:47.0000] <JakeA>
Well this is paint rather than layout

[04:02:09.0000] <annevk>
Ah true, I just group all of those together usually

[04:02:17.0000] <jgraham>
Right, WR doesn't make layout fast, it makes paint fast. Parellel layout should help with layout

[04:02:24.0000] <jgraham>
Which ofc Servo already has

[04:02:45.0000] <jgraham>
It just doesn't have things like correct implementations of Location

[04:02:56.0000] <jgraham>
Or form controls that don't suck

[04:03:07.0000] <jgraham>
*parallel

[04:03:37.0000] <JakeA>
it breaks loads of rendering too, but it's early days

[04:04:08.0000] <nox>
annevk: Lol @ 80%.

[04:04:23.0000] <nox>
hgl: 80% + 80% is 100% when you take into account that channel's topic.

[04:04:42.0000] <JakeA>
My demo is pretty kind to Servo as it uses CSS that it doesn't mess up

[04:05:54.0000] <hgl>
nox, sorry, still don't quite understand, "that channel's topic"?

[04:06:08.0000] <nox>
hgl: "#whatwg https://whatwg.org/ — logs: http://krijnhoetmer.nl/irc-logs/ & http://logbot.glob.com.au/ — stats:  http://gavinsharp.com/irc/whatwg.html — Please leave your sense of logic at the door, thanks!"

[04:06:28.0000] <jgraham>
My impression has been that it's relatively better at CSS-derived stuff than at DOM-derived stuff, although there have been shifts in the contributors since I formed that opinion such that it may no longer be the case

[04:06:44.0000] <hgl>
nox, ok, lol

[04:07:09.0000] <nox>
jgraham: We have improved many performance bottlenecks in DOM, but there are still many.

[04:07:23.0000] <jgraham>
nox: Not just performance but missing features

[04:07:31.0000] <nox>
jgraham: That too. :D

[04:07:42.0000] <jgraham>
But yeah, I guess it's also true that it doesn't yet have world-beating DOM performance

[04:07:46.0000] <nox>
jgraham: contentWindow, document.write, NodeIterator, CSSOM…

[04:07:56.0000] <nox>
MutationObserver.

[04:08:00.0000] <jgraham>
Well, quite

[04:08:08.0000] <nox>
Basically every complex part is left as an exercice to the reader. :P

[04:08:14.0000] <hgl>
a quick question, why no browsers have implemented the nice node.closest() node.query() apis?

[04:08:34.0000] <nox>
hgl: Because it requires a specific part of CSS selectors 4,

[04:08:39.0000] <nox>
hgl: namely scoped selectors.

[04:10:28.0000] <hgl>
nox, i see, thx

[04:10:58.0000] <nox>
hgl: I started a branch for css4 stuff in rust-selectors, but days are 24 hours long.

[04:11:25.0000] <hgl>
nox, what about append & prepend ? those don't need selectors 4 i think?

[04:12:06.0000] <hgl>
nox, you contribute to rust? thank for you hard work....

[04:12:10.0000] <nox>
hgl: Servo supports them, that's all I know. :P

[04:12:27.0000] <nox>
hgl: Servo contributor, starting at Mozilla in two weeks. :)

[04:12:48.0000] <hgl>
awesome!

[04:12:51.0000] <nox>
I mostly do DOM stuff and Ms2ger is trying to coerce me into spec editing.

[04:13:25.0000] <hgl>
wonder if firefox is ever going to replace gecko with servo. :)

[04:13:36.0000] <nox>
hgl: https://wiki.mozilla.org/Oxidation

[04:15:09.0000] <ondras>
good naming :)

[04:15:31.0000] <hgl>
agreed :)

[04:15:35.0000] <nox>
As long as no one calls that nox, I will be happy.

[04:15:54.0000] <nox>
/me already gets highlighted enough whenever someone mentions some headless Debian package.

[05:10:08.0000] <JakeA>
annevk: https://github.com/w3c/webcomponents/issues/369#issuecomment-191572976 "That means either sharing the registry with the parent (per the current spec) or just saying that they have no registry" does the latter mean that custom elements wouldn't work in iframes?

[05:11:51.0000] <annevk>
JakeA: it depends on where you create them

[05:15:53.0000] <Domenic>
It depends on what they extends actually

[05:17:18.0000] <Domenic>
class extends iframe.contentWindow.HTMLElement vs. class extends window.HTMLElement

[05:18:25.0000] <annevk>
Maybe the constructor folk would have put the constructors on document instances

[05:18:41.0000] <annevk>
new document.HTMLAudioElement()

[05:30:20.0000] <JakeA>
Could win.defineElement set a symbol on the class setting the default document?

[05:31:20.0000] <JakeA>
new MyCustomEl() would throw if that symbol wasn't set

[05:32:26.0000] <nox>
What's wrong with keeping them on the global?

[05:32:34.0000] <nox>
Shouldn't they rather behave like proper ES classes?

[05:33:01.0000] <JakeA>
nox: document.createElement know which document to create the elements for

[05:33:06.0000] <JakeA>
nox: new Whatever() doesn't

[05:33:27.0000] <nox>
So use document.createElement and don't mess with putting interface objects in the middle of nowhere, no?

[05:35:36.0000] <nox>
JakeA: I could also just read the thread and shut up.

[05:51:48.0000] <Domenic>
JakeA: sure, that is one design, is maintaining a global cross-realm mapping table of class instances to documents

[05:51:59.0000] <Domenic>
I guess we should mention it

[06:22:47.0000] <annevk>
Cross-realm seems like a bad mismatch with JavaScript

[06:32:44.0000] <Ms2ger>
annevk, are there plans to pull CSP monkeypatches into HTML?

[06:47:38.0000] <Ms2ger>
https://github.com/whatwg/html/issues/271

[06:59:13.0000] <annevk>
Ms2ger: mkwst usually takes care of that

[07:00:07.0000] <mkwst>
Yeah. But he's a bit unreliable.

[07:00:44.0000] <mkwst>
I think there are still a few things missing from HTML and Fetch, but I haven't written them yet.

[07:06:00.0000] <Ms2ger>
mkwst, fyi, I filed https://github.com/tc39/ecma262/issues/450

[07:07:33.0000] <mkwst>
Ms2ger: thank you.

[07:14:26.0000] <Ms2ger>
Domenic, thanks

[07:14:58.0000] <Domenic>
Seriously, what a jerk

[07:17:15.0000] <Ms2ger>
@jspedant

[07:17:18.0000] <Ms2ger>
Appropriate handle

[07:18:12.0000] <jgraham>
At risk of being pedantic, it's not, since he was wrong

[07:20:20.0000] <Ms2ger>
(Also, no way in hell I'm going to subscribe to es-discuss)

[07:20:22.0000] <Domenic>
literal loling going on here, jgraham

[07:36:13.0000] <Domenic>
mkwst: what does CSP do to eval and Function? They always throw a TypeError?

[07:36:24.0000] <Domenic>
If anyone has a test CSP page that'd be helpful.

[07:37:53.0000] <Domenic>
lol in Firefox it throws an Error

[07:37:59.0000] <Domenic>
I guess this is entirely underspecified

[07:38:06.0000] <Domenic>
so I will just let hosts do what they want

[07:41:57.0000] <Ms2ger>
154 MSG_DEF(JSMSG_CSP_BLOCKED_EVAL,        0, JSEXN_ERR, "call to eval() blocked by CSP")

[07:41:58.0000] <Ms2ger>
155 MSG_DEF(JSMSG_CSP_BLOCKED_FUNCTION,    0, JSEXN_ERR, "call to Function() blocked by CSP")

[07:42:14.0000] <Ms2ger>
I imagine we'd be willing to change that to a TypeError

[07:42:24.0000] <Domenic>
I will let the CSP spec define it

[07:42:37.0000] <Domenic>
Instead of having the hook return true/false and having ES define it's a TypeError

[07:43:08.0000] <Ms2ger>
wfm either way

[07:43:28.0000] <Ms2ger>
The latter is closer to what SpiderMonkey does, but eh

[07:43:52.0000] <mkwst>
Domenic: https://www.w3.org/TR/CSP2/#directive-script-src

[07:44:15.0000] <Domenic>
mkwst: I was looking at CSP4.

[07:44:16.0000] <mkwst>
CSP2 waved its hands around the question, and I haven't written the relevant bits of CSP3 yet.

[07:44:30.0000] <mkwst>
If you have a copy of CSP4, send it over, please.

[07:44:35.0000] <mkwst>
I'd like to skip a few years of mistakes. :)

[07:44:51.0000] <Domenic>
lol 3 i guess

[07:45:02.0000] <Domenic>
mkwst: what should we do if you do someOtherFrame.eval() from within a CSPed frame

[07:45:17.0000] <mkwst>
1. Why do people do these things.

[07:45:31.0000] <Domenic>
to get around CSP I guess :P

[07:45:38.0000] <mkwst>
2. We can either take the caller's CSP into account, or the callee's CSP into account.

[07:45:49.0000] <Domenic>
or both!?!

[07:45:57.0000] <mkwst>
I don't have strong opinions, but I think I'd lean towards the former.

[07:46:09.0000] <mkwst>
Or both, I guess. But that sounds like work.

[07:46:09.0000] <Domenic>
caller sounds simpler

[07:46:13.0000] <Domenic>
I will pass both to be explicit

[07:46:20.0000] <Domenic>
That way if CSP explicitly ignores one that's clear

[07:46:27.0000] <mkwst>
Sounds reasonable.

[07:57:15.0000] <Ms2ger>
Domenic, fwiw, SM looks at the global of the callee, so I guess that would get around csp

[07:57:34.0000] <Domenic>
Won't it be good to have this all specified nicely ;)

[07:58:33.0000] <Ms2ger>
Hoping for a future without COMEFROM :)

[07:58:48.0000] <Ms2ger>
And thanks for picking it up so quickly

[08:00:27.0000] <Domenic>
honestly i wouldn't have done so if this guy hadn't been a jerk about it :P

[08:01:28.0000] <Ms2ger>
:D

[08:01:47.0000] <annevk>
He wasn't very friendly either about my blacklist/whitelist PR :/

[08:02:00.0000] <annevk>
Some people

[08:04:44.0000] <Domenic>
he's not very friendly in meetings either, by total coincidence

[08:37:08.0000] <nox>
Domenic: The thread scares me.

[08:37:23.0000] <Domenic>
nox: which? HTMLAll?

[08:37:25.0000] <nox>
Domenic: Would be nice for someone to write some summary of it.

[08:37:28.0000] <nox>
Domenic: Document.all

[08:37:53.0000] <nox>
I saw "0x0" and it was scary.

[08:38:27.0000] <Domenic>
yes

[08:38:28.0000] <Domenic>
great times

[08:38:36.0000] <Domenic>
i have tried to keep the jsbin and PR updated

[08:39:45.0000] <nox>
Domenic: I guess we could keep unsigned long or DOMString,

[08:39:50.0000] <nox>
Domenic: but then we still have to check the string.

[08:40:00.0000] <nox>
But it could make the TypeScript people happier, I don't know.

[08:40:02.0000] <Domenic>
nox: that is what we do

[08:40:07.0000] <Domenic>
in the PR

[08:40:20.0000] <Domenic>
nox: https://github.com/whatwg/html/pull/780/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebR7095

[08:40:21.0000] <nox>
Ok so I'm like, very late at the party?

[08:40:32.0000] <nox>
I saw that but I thought it was still being discussed.

[08:40:42.0000] <Domenic>
haha ok :P

[08:41:15.0000] <annevk>
Not sure I'd call document.all a party

[08:42:07.0000] <Domenic>
nox: is your "Given the binding of WebIDL union types to ECMAScript values:" saying that conversions to strings are performed before conversions to numeric types?

[08:42:21.0000] <nox>
Domenic: Yes.

[08:42:23.0000] <jgraham>
It's like a party where the host was already drunk and all the guests have spent the whole night trying to avoid stepping in the vomit

[08:42:30.0000] <nox>
Domenic: Is that bad?

[08:42:36.0000] <Domenic>
nox: ok so it's still a good idea to get rid of unsigned long since it's pointless

[08:42:43.0000] <nox>
Mmh.

[08:42:48.0000] <nox>
What if I have an arbitrary object,

[08:42:53.0000] <nox>
that stringifies as "0",

[08:43:07.0000] <nox>
is that DOMString or unsigned long for the insane current implementations of Document.all?

[08:44:03.0000] <nox>
Domenic: I'm afraid the TypeScript people are going to complain about document.all(0) not being correctly typed.

[08:44:13.0000] <Domenic>
nox: they can write their own spec

[08:44:17.0000] <nox>
Ah ah.

[08:44:41.0000] <nox>
Domenic: Also, no idea why you would use ugly historical APIs from fancy TypeScript

[08:45:11.0000] <Domenic>
it seems like Edge has some kind of pipeline where alongside updating IDL files you must also update .d.ts files that they ship with Visual Studio or something

[08:46:29.0000] <nox>
Domenic: Sorry, you misunderstood me.

[08:46:39.0000] <nox>
Domenic: My quote was only about string values.

[08:46:49.0000] <nox>
Let me put the step just before in a new comment.

[08:48:28.0000] <Domenic>
nox: oh I see

[08:48:57.0000] <Domenic>
so the step is still kind of pointless since it's normatively the same to just treat everything as a string, but at least it's not dead code

[08:49:10.0000] <Domenic>
well it's maybe not the same

[08:49:24.0000] <Domenic>
{ toString() { return "42"; } valueOf() { return 43; } }

[08:49:35.0000] <nox>
Domenic: Ugh. :(

[08:52:24.0000] <nox>
Domenic: Are you sure it's not 42 with the current code?

[08:53:08.0000] <Domenic>
nox: oh you're right

[08:53:28.0000] <nox>
Domenic: And it would be the same with just DOMString AFAICT.

[08:54:00.0000] <nox>
Domenic: I have no idea what browsers do though anyway.

[08:57:39.0000] <nox>
Domenic: document.all(({ 'toString': function () { return "1"; }, 'valueOf': function () { return 0; } })) returns <head> in Safari.

[08:58:17.0000] <Domenic>
good!

[09:00:19.0000] <nox>
Anyway, Real Life is calling, see you later maybe.

[09:00:45.0000] <Domenic>
i remember real life...

[09:00:52.0000] <Domenic>
before my life was consumed by document.all

[09:01:03.0000] <Ms2ger>
Likewise

[09:23:04.0000] <annevk>
Domenic: do we want https://www.w3.org/Bugs/Public/show_bug.cgi?id=28566 still?

[09:23:59.0000] <Domenic>
annevk: yes, I think authors would really appreciate it

[09:24:18.0000] <Domenic>
at least, as long as implementers think it's OK

[09:24:43.0000] <annevk>
clone = global.structuredClone(value, transfer = [])

[09:24:53.0000] <annevk>
or do we also want to expose the transferList? Hmm

[09:24:54.0000] <Domenic>
Yeah

[09:25:07.0000] <Domenic>
We could move it to GitHub and ask authors for use cases + browser vendors for "will you implement this"

[09:25:28.0000] <annevk>
Will do once I figure out what the return value should be

[09:27:54.0000] <annevk>
Okay, we don't need [[TransferList]] since that is only for ports and those are only useful if you actually go elsewhere with this

[09:53:20.0000] <annevk>
Does anyone else get "You signed in with another tab or window. Reload to refresh your session." a lot on GitHub?

[09:53:33.0000] <annevk>
Why can't they just make it work

[09:58:19.0000] <miketaylr>
annevk: i don't think i've seen that one :/

[09:58:24.0000] <nox>
Domenic: Please double check that 2^32 value, we never know. :P

[09:58:49.0000] <miketaylr>
i know karl gets strange github errors i've never seen (from japan)

[10:17:03.0000] <JakeA>
annevk: Domenic: once the custom element constructor thing is solved, does that enable new HTMLDivElement() etc?

[10:18:10.0000] <annevk>
JakeA: we could have HTMLDivElement() if we wanted to

[10:18:55.0000] <annevk>
JakeA: it might be slightly better if we first decide if there are any required arguments I suppose, but I don't think there should be

[10:19:36.0000] <JakeA>
annevk: I thought there were different elements that share the same constructor, but can't remember what they were

[10:19:58.0000] <JakeA>
If there are some, maybe tag name is an optional arg

[10:20:01.0000] <annevk>
JakeA: ah yes, I think we should stop that, if we can

[10:20:10.0000] <annevk>
JakeA: just give each element a class

[10:20:20.0000] <JakeA>
yeah, that's a better solution

[10:20:35.0000] <annevk>
I'm a little worried about compat, but hopefully it's fine

[10:20:50.0000] <annevk>
This hasn't really come up lately since nobody has been asking about it

[10:21:15.0000] <annevk>
I've also wondered what happened to your promise state proposal, of adding that to most things

[10:23:07.0000] <JakeA>
ohhh the .ready stuff? Yeah, that would be nice too. If I run into some more time I should do a PR

[10:28:31.0000] <annevk>
JakeA: yeah, would love that

[10:47:44.0000] <miketaylr>
has anyone in the "remove appCache" camp thought about what happens to code calling methods or props on window.applicationCache?

[10:48:00.0000] <miketaylr>
(https://bugzilla.mozilla.org/show_bug.cgi?id=1252860#c1)

[11:01:43.0000] <annevk>
miketaylr: not really

[11:02:33.0000] <miketaylr>
annevk: only one way to find out...

[11:03:11.0000] <annevk>
miketaylr: could make them all no-op

[11:03:23.0000] <annevk>
miketaylr: if problematic

[11:03:47.0000] <miketaylr>
window.applicationCache.toString() == [object DoucheBag]

[11:03:59.0000] <miketaylr>
annevk: yeah, i'll keep investigating to see how big a problem it will be

[11:04:28.0000] <annevk>
heh

[11:54:40.0000] <danbeam>
does anybody know if PromiseResolver removed from https://dom.spec.whatwg.org/?  https://developer.mozilla.org/en-US/docs/Web/API/PromiseResolver links to https://dom.spec.whatwg.org/#promiseresolver but that <a name> no longer exists (nor is "PromiseResolver" in that document)

[11:54:51.0000] <danbeam>
if PromiseResolver was removed from*

[11:55:13.0000] <danbeam>
annevk: ^

[11:56:07.0000] <annevk>
danbeam: promises are defined in ECMAScript these days

[11:56:29.0000] <danbeam>
annevk: ok, will poke around there

[11:56:32.0000] <danbeam>
annevk: thx

[11:56:56.0000] <annevk>
danbeam: that page can prolly be removed

[11:57:04.0000] <danbeam>
annevk: yeah, was wondering who to bother about that

[11:57:17.0000] <danbeam>
annevk: i suppose i can do it myself and see if I have access / who screams

[11:57:51.0000] <annevk>
danbeam: yeah, teoli is my goto MDN contact

[11:58:29.0000] <annevk>
danbeam: but with wikis you can just go ahead and answer questions later 😀

[11:59:13.0000] <danbeam>
annevk: in trying to edit i've struck out 3 times with github oauth / persona, requires authentication at least

[11:59:29.0000] <danbeam>
teoli is a previous editor

[12:02:58.0000] <annevk>
danbeam: aww bummer, cannot help with that, ask on #mdn on Moziila IRC

[12:58:25.0000] <annevk>
Domenic: can't believe I didn't think of it before, but we should do s/IDL-defined object/Platform object/

[12:58:44.0000] <annevk>
Domenic: maybe tomorrow

[13:04:55.0000] <zcorpan>
Domenic: document.all(4294967296)   // looks up the element at index 0  - does this match any browser?

[13:09:40.0000] <zcorpan>
i might actually start to use document.all(0) instead of document.documentElement, i always manage to make a typo in the latter :-)

[13:20:15.0000] <rniwa>
Domenic: hi

[13:20:23.0000] <Domenic>
rniwa: hi

[13:21:25.0000] <rniwa>
Domenic: so it turns out that sharing registry with window-less documents won't work

[13:21:42.0000] <rniwa>
Domenic: Because even in that case, HTMLElement constructor can't figure out to which document it belongs

[13:22:46.0000] <rniwa>
Domenic: so you end up creating a document in window.document

[13:22:47.0000] <Domenic>
rniwa: it just looks up the HTMLElement constructor's window's active document

[13:22:51.0000] <rniwa>
Domenic: and adopting it

[13:23:12.0000] <Domenic>
which if the registry is shared, will have all the same entries as the createElement() ones

[13:23:16.0000] <Domenic>
*createDocument()

[13:24:46.0000] <rniwa>
Domenic: but then ownerDocument will be wrong initially and it would be observable in the custom element's constructor

[13:25:20.0000] <Domenic>
Ah I see

[13:25:27.0000] <Domenic>
ownerDocument as the problem, not just the registry

[13:26:18.0000] <rniwa>
Domenic: since I really don't want to punish the common case by forcing authors to specify document

[13:26:24.0000] <Domenic>
Just disallow it in documents without associated windows?

[13:26:29.0000] <rniwa>
Domenic: and you guys don't want to make document optional

[13:26:36.0000] <rniwa>
Domenic: we just need to disallow in window-less documents

[13:26:48.0000] <Domenic>
sounds good to me

[13:27:19.0000] <Domenic>
thanks for discovering all the edge cases first

[13:28:42.0000] <rniwa>
Domenic: nope, I had to talk with my colleagues about this anyway

[13:52:13.0000] <rniwa>
Domenic: a WebKit patch is forthcoming ;) https://bugs.webkit.org/show_bug.cgi?id=154944

[14:17:03.0000] <peterjoel>
hi, I submitted a PR to some tests on DOMMatrix, but the build failed in a way that looks like it needs to just be retried

[14:17:04.0000] <peterjoel>
https://github.com/w3c/csswg-test/pull/1060

[14:17:30.0000] <peterjoel>
https://travis-ci.org/w3c/csswg-test/builds/113513577#L318

[14:17:46.0000] <peterjoel>
“No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.”

[14:22:12.0000] <peterjoel>
Also, I need to create new tests for DOMMatrix and DOMMatrixReadOnly. Shall I just make PRs?


2016-03-04
[19:12:12.0000] <annevk>
Domenic: was also thinking of allowing Error to be cloned per JakeA's request since aklein doesn't think that is problematic

[19:12:51.0000] <annevk>
Domenic: if you remove the slot it would be though, but I suppose that is unlikely now

[19:16:36.0000] <Domenic>
Seems reasonable. I should probably just close that PR.

[19:27:45.0000] <MikeSmith>
rniwa: it’s really nice to see the implementation coming together and the wrinkles getting ironed out

[19:28:51.0000] <MikeSmith>
and the iteration back into spec discussion that falls out from the implementation work

[19:34:37.0000] <rniwa>
MikeSmith: indeed.

[21:48:25.0000] <annevk>
Hmm cloning Error and friends is a little trickier than I thought

[21:51:27.0000] <annevk>
I suspect browsers actually have more branding on them than just [[ErrorData]]

[02:17:19.0000] <annevk>
nox: what setup does Servo have for https://github.com/whatwg/dom/issues/34?

[02:21:47.0000] <zcorpan>
https://html.spec.whatwg.org/#attr-translate - does this mean Text node children or Text node descendants?

[02:23:03.0000] <annevk>
zcorpan: children

[02:23:25.0000] <annevk>
zcorpan: it inherits

[02:23:44.0000] <zcorpan>
ah

[02:55:57.0000] <MikeSmith>
I had meant to make time to look at the “allow <link> in body for external resource links” change before it landed, as far as the document-conformance part at least

[02:56:19.0000] <MikeSmith>
need to figure out how to make more time for stuff going forward

[02:56:59.0000] <MikeSmith>
anyway it seems like zcorpan looked at that part in detail and if so then I’m confident

[02:57:25.0000] <MikeSmith>
now I need to update the checker

[03:02:09.0000] <MikeSmith>
well

[03:04:41.0000] <MikeSmith>
one thing I notice is that we ended up with no (informative) list in one place in the spec that says, The attributes that are body-ok are pingback, prefetch, and stylesheet.

[03:05:01.0000] <MikeSmith>
the lack of that seems suboptimal for author/developer readers

[03:05:46.0000] <MikeSmith>
because we are forcing them to look at the spec text of every single rel value themselves to figure out which ones are body-ok

[03:06:45.0000] <MikeSmith>
it at least could be flagged in the table just after https://html.spec.whatwg.org/multipage/semantics.html#body-ok

[03:07:13.0000] <MikeSmith>
zcorpan:

[03:07:22.0000] <MikeSmith>
zcorpan: ⬆

[03:07:54.0000] <MikeSmith>
if you agree, I’ll raise a follow-up PR that adds it

[03:08:10.0000] <zcorpan>
MikeSmith: good idea

[03:08:23.0000] <zcorpan>
new column i guess

[03:08:24.0000] <MikeSmith>
hai

[03:08:26.0000] <MikeSmith>
yeah

[03:25:34.0000] <MikeSmith>
hmm that change also

[03:26:44.0000] <MikeSmith>
* that change also muddied up the relationship of the 「Thus, rel="next" is the same as rel="NEXT".」example to the spec text that previously had immediately preceded it

[03:26:59.0000] <MikeSmith>
will correct that too

[03:46:18.0000] <zcorpan>
MikeSmith: oops. i should be checking the output more carefully

[03:48:19.0000] <MikeSmith>
no biggy

[03:50:56.0000] <MikeSmith>
I’m not too keen on the vagueness of “Certain keywords are said to be”, so will futz that part too

[03:52:03.0000] <MikeSmith>
which is going to end up maybe with a bit belt-and-suspenders redudancy but I think it will still be better for readers

[03:52:06.0000] <MikeSmith>
more clear

[04:02:38.0000] <zcorpan>
MikeSmith: note that other specs can define keywords too, and say that those are body-ok (e.g. preload)

[04:03:53.0000] <MikeSmith>
zcorpan: well, so we should say that too then

[04:04:03.0000] <MikeSmith>
instead of leaving it unstated

[04:04:24.0000] <MikeSmith>
because the current spec text says nothing about that as far as I can see

[04:04:39.0000] <MikeSmith>
/me re-reads to see if he missed something

[04:06:10.0000] <zcorpan>
4.6.6.17 Other link types needs to mention body-ok

[04:07:13.0000] <MikeSmith>
/me looks there

[04:08:11.0000] <MikeSmith>
hmm yeah

[04:08:38.0000] <MikeSmith>
this is becoming a bit of a thread-pulling thing

[04:09:16.0000] <MikeSmith>
because that means the microformats wiki also needs to be updated

[04:11:57.0000] <MikeSmith>
zcorpan: right? I mean a column needs to be added to the tables there

[04:13:07.0000] <zcorpan>
MikeSmith: it depends. could say that it's the responsibility of the Specification to talk about body-ok if it wants it allowed in the body, it doesn't need to be in the wiki

[04:13:42.0000] <MikeSmith>
yeah

[04:13:58.0000] <MikeSmith>
you’re right

[04:14:18.0000] <MikeSmith>
that’s better

[04:23:04.0000] <nox>
annevk: I implemented an UnbindingContext.

[04:23:18.0000] <nox>
For the removing steps that are called recursively.

[04:25:04.0000] <nox>
annevk: You don't explain why you want to call them on ancestors though.

[04:36:26.0000] <annevk>
nox: I don't

[04:36:39.0000] <annevk>
nox: but insertion steps isn't yet called on descendants

[04:36:41.0000] <nox>
annevk: Ok, misunderstood what it was about.

[04:36:47.0000] <nox>
/me annevk: Sounds like a bug indeed.

[04:37:03.0000] <nox>
annevk: Wait, you sure?

[04:37:19.0000] <nox>
annevk: https://dom.spec.whatwg.org/#concept-node-insert-ext Step 6?

[04:37:41.0000] <annevk>
nox: how does that include descendants?

[04:37:43.0000] <nox>
Oh right, never mind.

[04:37:48.0000] <nox>
Just woke up. :P

[04:38:23.0000] <annevk>
Also, that the removing steps are passed oldPreviousSibling doesn't match any browser and that we pass oldParent is weird, because for most descendants it'll be an ancestor, not a parent

[04:38:35.0000] <annevk>
I guess I'll just go with oldAncestor

[04:38:52.0000] <nox>
annevk: We discussed that.

[04:39:03.0000] <nox>
We discussed that last year, when I implemented that crap in Servo.

[04:39:33.0000] <annevk>
I know we did, this issue is old

[04:39:42.0000] <nox>
annevk: I wanted two kind of hooks, and someone here convinced me that we could just distinguish parent from ancestor by checking whether the child's parent is oldParent.

[04:39:56.0000] <nox>
annevk: Want me to link Servo's code?

[04:40:08.0000] <annevk>
nox: sure, doesn't hurt

[04:40:40.0000] <annevk>
nox: I believe Chrome has distinct calls for parent change and ancestor change, but I'm not sure we need that in the spec

[04:41:02.0000] <nox>
annevk: Mmmh, we don't, but it might make some prose a bit weirder.

[04:41:30.0000] <nox>
"If child's parent isn't oldParent, abort these steps" or things like that.

[04:41:55.0000] <nox>
annevk: Every time I look at our implementation of DOM, some step numbers changed. :(

[04:42:18.0000] <annevk>
Yeah, maybe, but we could abstract things too with prose if it get unwieldy

[04:42:35.0000] <annevk>
nox: what can I say, the web evolves

[04:42:42.0000] <nox>
:D

[04:42:46.0000] <annevk>
nox: also, I think you might be responsible for most recent changes there

[04:43:00.0000] <annevk>
Oooh, maybe zcorpan is

[04:43:37.0000] <zcorpan>
did i break something?

[04:44:01.0000] <nox>
annevk: We recursively call insertion and removing steps on all descendants,

[04:44:13.0000] <nox>
annevk: and for removing, here is the data passed around: https://github.com/servo/servo/blob/master/components/script/dom/node.rs#L2471-L2482

[04:44:26.0000] <annevk>
zcorpan: you might have broken where comments in Servo point to

[04:44:31.0000] <annevk>
zcorpan: sorry for pinging

[04:44:36.0000] <nox>
annevk: We cache the index of the removed node and whatnot because we piggy-back this loop to update DOM ranges.

[04:44:39.0000] <zcorpan>
ah

[04:44:59.0000] <nox>
annevk, zcorpan: Oh well, that's an E-Easy issue for newcomers, maybe I should thank zcorpan. ;)

[04:45:10.0000] <annevk>
nox: curious that you pass the oldPreviousSibling

[04:45:17.0000] <annevk>
nox: browsers don't

[04:45:25.0000] <nox>
annevk: We do use it for some reason, let me find where again.

[04:45:38.0000] <nox>
annevk: The stec want it, no?

[04:45:41.0000] <nox>
spec* wtf

[04:45:53.0000] <annevk>
I don't want it if browsers don't have it

[04:45:59.0000] <nox>
annevk: Oh yeah,

[04:46:05.0000] <nox>
annevk: UnbindContext::index needs it.

[04:46:28.0000] <nox>
annevk: https://github.com/servo/servo/blob/master/components/script/dom/node.rs#L2503

[04:46:38.0000] <nox>
annevk: I didn't want to compute the index if nothing needed it.

[04:49:06.0000] <nox>
annevk: That there is the old previous sibling is not public in the API of UnbindContext btw,

[04:49:14.0000] <nox>
annevk: so feel free to nuke it away, even Servo doesn't care.

[04:50:41.0000] <annevk>
Good times

[04:50:58.0000] <annevk>
The reason this comes up now by the way is that this will get more complicated with shadow DOM

[04:51:21.0000] <annevk>
Because then we don't just include descendants, but also any shadow trees hosted by any descendants, etc.

[04:54:22.0000] <nox>
annevk: I see.

[04:56:17.0000] <nox>
annevk: Just realised Document.all is still going on.

[04:56:37.0000] <annevk>
24/7 entertainment

[04:58:02.0000] <nox>
annevk: Especially given we are all over the world. :D

[04:58:07.0000] <nox>
It really gets 24/7 comments.

[05:09:12.0000] <annevk>
Sigh, bikeshed again changes random shit in the output

[05:09:32.0000] <annevk>
It's getting to the point where I just avoid editing bikeshed specs

[05:13:05.0000] <JakeA>
Would love bikeshed to switch to node, I think it'd be easier to contribute then. Never been able to get bikeshed running locally, kept rabbit-holeing on dependencies that wouldn't install

[05:19:48.0000] <annevk>
It's such a non-deterministic piece of crap ugh

[05:20:09.0000] <annevk>
I was hoping to make some progress on DOM but it's no fun if the tools fall apart

[05:22:30.0000] <annevk>
I think I actually might be better off with Anolis

[05:22:53.0000] <annevk>
bikeshed has been nothing but pain and all the promised features of auto-linking are in a constant state of broken

[05:33:31.0000] <nox>
JakeA: I don't see what switching to Node brings.

[05:33:42.0000] <nox>
JakeA: That still means dependencies to install.

[05:34:21.0000] <nox>
annevk: What was used before bikeshed?

[05:34:29.0000] <annevk>
Anolis

[05:34:37.0000] <nox>
annevk: And why does it break stuff all the time?

[05:34:39.0000] <JakeA>
nox: in my experience it's way simpler. Node & npm install easily, then it's just npm install

[05:35:04.0000] <JakeA>
nox: compare that to https://github.com/tabatkins/bikeshed/blob/master/docs/install.md

[05:35:04.0000] <annevk>
nox: I have no idea, presumably because Tab keeps landing changes without verifying that they don't change existing outputs

[05:35:07.0000] <nox>
JakeA: Didn't encounter any problem with building Bikeshed, and given what I hear about npm…

[05:35:30.0000] <JakeA>
I don't know what you hear

[05:35:50.0000] <annevk>
nox: you can review https://github.com/whatwg/dom/pull/184 though

[05:36:24.0000] <nox>
JakeA: Same experience as you with bikeshed-as-Python-tool, mostly.

[05:36:45.0000] <nox>
annevk: Filed a ticket on bikeshed btw?

[05:36:56.0000] <annevk>
yeah, see PR

[05:37:23.0000] <nox>
annevk: Can we really say the descendant of an inserted node is an inserted node?

[05:37:32.0000] <JakeA>
nox: where are you hearing that from?

[05:37:34.0000] <annevk>
yes

[05:37:46.0000] <nox>
JakeA: Frustrated people on the IRC.

[05:38:17.0000] <nox>
annevk: Not renaming the newNode in the loop?

[05:38:26.0000] <JakeA>
The complaints I hear about NPM are speed rather than complexities around having to install a load of global dependencies with sudo

[05:38:38.0000] <JakeA>
I can't remember the last time I had to do that with npm

[05:38:53.0000] <annevk>
nox: I guess we could rename that node

[05:39:27.0000] <jgraham>
JakeA: TabAtkins' instructions are crazy. Install python stuff into virtualenvs not globally

[05:40:00.0000] <jgraham>
But my experience is that everyone likes the package manager they are used to

[05:40:17.0000] <annevk>
JakeA: would happily switch to something node-based

[05:40:59.0000] <jgraham>
To me "we should rewrite X because it's not in javascript" is terrible reasoning

[05:40:59.0000] <JakeA>
jgraham: ahh, maybe it is just an instructions thing. If memory serves I was getting tripped up on the macports stuff.

[05:41:16.0000] <jgraham>
Yeah, I wouldn't write the instructions like that

[05:41:22.0000] <nox>
jgraham: Same.

[05:41:56.0000] <annevk>
jgraham: the reasoning is more that it'd be maintained by JakeA and not TabAtkins

[05:42:09.0000] <JakeA>
/me runs away

[05:42:31.0000] <annevk>
ECMAScript has something node-based too

[05:42:43.0000] <JakeA>
But if the tool is for a web developer audience, writing it in web technologies seems better for a comunity

[05:42:47.0000] <annevk>
https://github.com/bterlson/ecmarkup

[05:43:04.0000] <JakeA>
for the community*

[05:43:06.0000] <jgraham>
If your answer was "we should Go from N tools to N-1 tools", that seems reasonable. If it's

[05:43:20.0000] <jgraham>
"we should go from N tools to N+1 tools" that's less reasonable

[05:43:30.0000] <Ms2ger>
Rust :)

[05:43:41.0000] <nox>
Says the guy who doesn't want to see codegen in Rust. :P

[05:44:14.0000] <jgraham>
I was going to say, write it in Rust, ship a binary that doesn't require any installation, and encourage web developers to broaden their skillset to contribute :)

[05:44:38.0000] <nox>
That being said,

[05:44:44.0000] <jgraham>
I guess Hixie would say the same but s/Rust/FreePascal/

[05:44:48.0000] <jgraham>
;)

[05:44:49.0000] <nox>
we do have a working HTML parser and that would be a good test.

[05:45:11.0000] <nox>
(Test as in "is that useful outside of Servo and its author's own projects".)

[05:47:33.0000] <jgraham>
nox: It also requires some rather large amount of free time to get it working :)

[05:47:44.0000] <jgraham>
(a useful spec generator, I mean)

[05:47:44.0000] <nox>
True. :)

[05:48:43.0000] <annevk>
Maybe gsnedders wants to do it again

[05:49:43.0000] <Ms2ger>
I know I don't

[05:51:57.0000] <annevk>
ecmarkup is prolly the best bet

[05:52:14.0000] <annevk>
although I haven't really tested its speed

[05:56:08.0000] <nox>
If I had that free time, I would rather rewrite our WebIDL parser in Rust.

[05:56:11.0000] <nox>
I don't have that free time.

[07:23:40.0000] <dbkaplun>
Is there some relation between whatwg and ecma262?

[07:23:58.0000] <Ms2ger>
Yes, Domenic :)

[07:25:01.0000] <dbkaplun>
Does WhatWG as a group have any influence over the JS spec or is it just Domenic?

[07:27:19.0000] <Ms2ger>
Not more than the sum of the people that make it up

[07:28:25.0000] <TabAtkins>
annevk: Woah, what in the actual fuck is going on with the <p> stuff.  I haven't touched that area in ages.

[07:29:52.0000] <annevk>
Hope you can excuse the vented frustration earlier

[07:30:11.0000] <Ms2ger>
(Please don't move back to anolis)

[07:30:56.0000] <TabAtkins>
Totally.  (Tho it's interesting that you're the only person I've heard such complaints from.)

[07:32:01.0000] <annevk>
Maybe nobody else actually looks at what's being generated?

[07:32:18.0000] <TabAtkins>
That's mostly true, yeah.

[07:32:22.0000] <annevk>
That's how the CSS WG operates, no?

[07:34:48.0000] <astearns>
fantasai complains about the output, but then just fixes things manually

[07:35:24.0000] <annevk>
Oh my

[07:38:10.0000] <nox>
Occasionally-venting-to-people-who-know-you-are-just-frustrated FTW.

[07:42:34.0000] <TabAtkins>
Luckily, most of her complaints are with the data source - a bunch of specs haven't been published in a while, and so she can't get good linking into the TR versions.

[07:43:09.0000] <TabAtkins>
(I just went thru a bug of hers with about a dozen complaints - one I'd already fixed, one I filed a new bug for, and the rest were just specs with bad or old markup.)

[07:43:41.0000] <TabAtkins>
annevk: Yo, I can't reproduce your <p> bug.  Those two paragraphs seem to gen just fine to me.

[07:44:26.0000] <annevk>
TabAtkins: you don't get a gigantic diff?

[07:45:02.0000] <annevk>
/me wonders what is going on then

[07:45:18.0000] <TabAtkins>
No, if I freshly gen the master branch, there's just a few points.  The biblio index part has a decent diff because I stopped generating useless self-links there.

[07:45:43.0000] <TabAtkins>
But otherwise it's just two constructors that the new widlparser code recognizes have optional args.

[07:49:29.0000] <TabAtkins>
annevk: Oh, *now* I see a problem.  I had to apply one of the changes in your branch.

[07:49:42.0000] <TabAtkins>
There must be something fucked up with comment handling.

[07:50:05.0000] <annevk>
I see, I think there's other comments

[07:50:14.0000] <TabAtkins>
Yeah, I'm confused.  Let me fiddle with this.

[07:50:49.0000] <TabAtkins>
(This is almost certainly not a recent problem, fwiw - I haven't touched the relevant parts of the code in a while. This is something old you're the first to hit.)

[07:51:18.0000] <annevk>
TabAtkins: oh wow, <script> element to script element does wonders

[07:51:24.0000] <Ms2ger>
Ha

[07:51:26.0000] <annevk>
TabAtkins: what is going on there?

[07:51:50.0000] <annevk>
I'll do script element for now then

[07:52:21.0000] <TabAtkins>
Ah, yeah, that's the problem.  Just figured it out myself.

[07:52:28.0000] <TabAtkins>
That's... interesting.

[07:54:09.0000] <annevk>
Are you parsing HTML with a regexp?

[07:55:12.0000] <TabAtkins>
Oh god no.

[07:55:27.0000] <TabAtkins>
I *am* parsing *Markdown* with a regex, which happens before the HTML parser has a chance to run.

[07:56:02.0000] <jgraham>
Now you have two problems?

[07:56:13.0000] <TabAtkins>
And my check for "am I entering a block that shouldn't have any processing done to it" is naive and just checks for the existence of <script>/<pre>/<style> start tags on the line.

[07:56:59.0000] <TabAtkins>
So it misfires on that comment line, and then the rest of your document stops being markdown-processed because you don't have a stray </script> anywhere. ^_^

[07:57:22.0000] <TabAtkins>
So you don't get paragraphs anymore.

[07:57:48.0000] <annevk>
I have no response

[07:58:02.0000] <TabAtkins>
Hey, Markdown is crazy pants and there's no official parser.

[07:58:52.0000] <TabAtkins>
(And I couldn't use one anyway, because the interaction of indented code blocks and html nesting is crazypants and would fuck everything up. Indented code blocks are a misfeature.)

[07:59:19.0000] <TabAtkins>
So anyway, I'll file a bug on myself and figure out how to deal with comments.

[07:59:50.0000] <TabAtkins>
For now, yeah, just don't put a literal "<script>" (or <pre> or <style> or <xmp>) inside of a comment.

[08:00:02.0000] <jgraham>
It does feel like the solution to "format X can't be parsed" might be "don't use format X"

[08:00:33.0000] <TabAtkins>
Tell that to everyone who loves Markdown (including me).

[08:02:10.0000] <annevk>
ecmarkup handles Markdown inclusion better I think

[08:02:27.0000] <annevk>
And has linking extensions on top that make it quite neat

[08:03:11.0000] <TabAtkins>
Ooh, hadn't heard of the linking extensions.

[08:04:22.0000] <annevk>
Stuff like "1. Let _x_ be ? SomeAbstractOperation(_y_)." links the operation

[08:04:46.0000] <annevk>
It's quite nice and makes ECMAScript one of the better formatted specifications out there

[08:04:56.0000] <annevk>
Platform is kind of a jungle compared to that

[08:05:46.0000] <nox>
Markdown has a specification now, no?

[08:06:13.0000] <annevk>
Not according to its inventor

[08:06:18.0000] <TabAtkins>
nox: Yeah, commonmark, but it still contains indented code blocks, which interact *terribly* with "let's mix lots of raw HTML into it too".

[08:06:36.0000] <nox>
Disregard inventor. :P

[08:06:55.0000] <TabAtkins>
Nobody cares what gruber thinks about it, since he refuses to "spec" anything further than "whatever bullshit perl I vomited into this file, bugs and all".

[08:07:31.0000] <nox>
I don't get his train of thought.

[08:07:40.0000] <annevk>
Given that every application of it requires slightly different extensions, he doesn't seem so wrong really

[08:08:09.0000] <annevk>
It's highly contextual

[08:08:33.0000] <nox>
Talking about contextual things,

[08:08:41.0000] <nox>
if someone is sad to have done too much bikeshed today,

[08:08:54.0000] <nox>
here is a photo of my cats thinking they are Legos. https://usercontent.irccloud-cdn.com/file/xRr4n7J1/1457096736.JPG

[08:09:38.0000] <nox>
It's important to have cats when doing spec editing.

[08:10:25.0000] <jgraham>
So there's something to eat your body if it all becomes too much and you lose the will to live?

[08:10:52.0000] <nox>
jgraham: So that if all is Hell, at least you have cats to pet.

[08:11:04.0000] <TabAtkins>
Hm, I was thinking I could do a preprocessing step to remove comments first (and restore them afterwards), but that won't help if you do <div title="hahaha here's a <script> tag fukker">.

[08:11:55.0000] <TabAtkins>
So maybe I'll just make the "I'm starting a block" check more restrictive, and require those tags to be the first non-WS content on their line. This has a chance of breaking things, tho.

[08:20:48.0000] <TabAtkins>
Okay, added a comment to the Breaking Changes Notification Thread, we'll see if anything shakes out.

[08:20:54.0000] <TabAtkins>
Thanks for finding the bug, annevk. ^_^

[08:21:24.0000] <annevk>
I hope you checked that fix on a couple of specs

[08:42:28.0000] <TabAtkins>
I haven't made the fix yet.

[08:42:41.0000] <TabAtkins>
Wont' for a couple days at least.

[08:52:36.0000] <Ms2ger>
TabAtkins, is http://www.adambarth.com/papers/2009/barth-caballero-song.pdf in the references database bikeshed uses, and how can I get it made so?

[08:52:55.0000] <TabAtkins>
specref.org is the place you want to check

[08:53:26.0000] <TabAtkins>
And it looks like no.

[08:53:40.0000] <Ms2ger>
Can I add it in a spec-local way?

[08:54:45.0000] <Ms2ger>
TabAtkins, ^

[08:55:16.0000] <TabAtkins>
Yeah, with a <pre class=biblio> block. https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md#bibliography, look at the first code-block in that section for an example.

[08:55:28.0000] <TabAtkins>
And I can get it into SpecRef no problem, I have commit rights now.

[08:56:38.0000] <TabAtkins>
Oh gosh I need to update some of the text in that documentation section.

[08:59:17.0000] <Ms2ger>
https://github.com/whatwg/mimesniff/pull/6

[08:59:19.0000] <Ms2ger>
/me poofs

[09:04:33.0000] <TabAtkins>
That... is a remarkably small diff for a Bikeshed move.

[09:14:01.0000] <annevk>
It's not done it seems

[09:14:11.0000] <annevk>
/me hopes Ms2ger coordinates with padenot

[11:37:21.0000] <gsnedders>
annevk: I have no interest in writing a spec generator, really. Maybe a touch of interest in trying to see if I can get it elegantly done with loop fusion. Maybe once the next PyPy and lxml releases come out see how much work is involved in getting bikeshed running there

[11:38:52.0000] <TabAtkins>
Iirc, I'm only stuck on Python 2 to make plinss's life easier, because Shepherd has some py2-only dependencies (involving Mercurial, I think).

[11:39:24.0000] <gsnedders>
TabAtkins: pypy is pretty much py2-only

[11:39:28.0000] <gsnedders>
but so much quicker

[11:39:35.0000] <TabAtkins>
Oh, cool.

[11:39:46.0000] <TabAtkins>
I'd love quicker! Free perf gains are always nice.

[11:39:52.0000] <gsnedders>
There *is* PyPy3k, but it's several releases behind CPython

[11:40:11.0000] <gsnedders>
Also it's slower than PyPy, because all the work on it has been about getting it complete rather than fast

[11:43:43.0000] <TabAtkins>
(Some clever applications of loop fusion would probably be good - a significant part of Bikeshed's runtime is running selectors, and a single double-size selector run once is much less expensive than two selectors run separately.)

[11:53:54.0000] <gsnedders>
TabAtkins: right, this was true in Anolis too, essentially. It's also why we really want to move to PyPy, a lot of the overhead of running selectors is interpreter overhead rather than anything inherently CPU expensive

[11:54:22.0000] <gsnedders>
TabAtkins: but it's why I'm really curious about Haskell for this, given loop fusion is pretty easy to achieve where needed, in part because of the purity

[13:12:12.0000] <aklein>
Domenic, annevk: so remember how I said it was fine to check enumerability as you go in structured clone?

[13:12:16.0000] <aklein>
I now think that's wrong

[13:12:48.0000] <Domenic>
aklein: you mean how I thought it was fine to trigger multiple proxy traps since proxies are disallowed? Or something else?

[13:12:57.0000] <aklein>
Domenic: not because of proxies

[13:13:06.0000] <aklein>
the issue is, which set of properties should we loop over?

[13:13:20.0000] <aklein>
the way the spec does it, we loop over all the own keys

[13:13:33.0000] <aklein>
and then interleave checks for enumerability with calls to [[Get]]

[13:13:43.0000] <Domenic>
ah, i see!

[13:14:17.0000] <aklein>
neither WebKit or Blink

[13:14:35.0000] <aklein>
do that

[13:14:36.0000] <aklein>
(they both check for enumerability up front)

[13:14:36.0000] <Domenic>
aklein: want to file it, or shall i?

[13:15:18.0000] <aklein>
Domenic: if you wouldn't mind....

[13:15:48.0000] <aklein>
I assume you're fine with checking enumerability before triggering any possible side effects?

[13:15:57.0000] <aklein>
(especially given it matches implementations :)

[13:17:04.0000] <Domenic>
aklein: yeah that sounds totally fine, I think the current spec is just doing that because it was easy to spec/matched some existing ES prose.

[13:17:16.0000] <Domenic>
The old spec said something like "for each own enumerable property" so this is kind of a regression

[13:20:10.0000] <Domenic>
aklein: wait, how is this observable again? concrete example?

[13:20:47.0000] <Domenic>
a throwing non-enumerable getter won't be triggered. a throwing enumerable getter will be. seems the same as before, assuming no proxies.

[13:35:49.0000] <nox>
annevk: Are pseudo-elements supposed to be handled in DOM's Element.matches?

[13:35:54.0000] <nox>
As per the spec currently, they are.

[13:36:10.0000] <nox>
Cc SimonSapin.

[13:36:38.0000] <nox>
http://logs.glob.uno/?c=mozilla%23servo#c379296

[13:37:17.0000] <SimonSapin>
specifically https://drafts.csswg.org/selectors-4/#evaluate-a-selector "APIs using this algorithm […] may optionally provide […] which pseudo-elements are allowed to show up in the match list, if any. If not specified, this defaults to allowing all pseudo-elements."

[13:50:06.0000] <SimonSapin>
nox: https://github.com/whatwg/dom/issues/185

[13:50:54.0000] <nox>
Cool.

[13:56:33.0000] <aklein>
Domenic: a getter that deletes another propety

[13:56:34.0000] <aklein>
property

[13:57:49.0000] <aklein>
Domenic: see, e.g., https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/fast/dom/Window/script-tests/postmessage-clone.js&l=142

[13:57:53.0000] <aklein>
er

[13:58:07.0000] <aklein>
in this case it'd be a getter that changes the enumerable-ness of another property

[13:58:09.0000] <aklein>
but you get the idea

[14:01:15.0000] <Domenic>
aklein: perfect, thanks

[14:03:29.0000] <aklein>
Domenic: existing implementations do seem to check for the existence of a property during the loop anyway, though it'd be awesome if we didn't have to do that

[14:03:54.0000] <Domenic>
aklein: oh i see, wow so many proxy traps being triggered

[14:04:45.0000] <aklein>
not really proxy related, just the existence of getters

[14:05:46.0000] <Domenic>
i guess i meant if we did allow proxies this isn't anywhere near how you would write the algorithm in order to minimize trap-triggering

[14:18:01.0000] <aklein>
Domenic: indeed :)

[15:24:23.0000] <nox>
Can anyone tell me if selectors4 still forbid nested :matches()? I remember it used to in the past but can't find it again in https://drafts.csswg.org/selectors/#matches. Did that change recently?

[15:25:57.0000] <nox>
TabAtkins: ^

[15:30:42.0000] <TabAtkins>
nox: Doesn't look like the requirements there anymore, so consider it gone.

[15:30:47.0000] <TabAtkins>
Certainly isn't a *recent* change, tho.

[15:31:28.0000] <nox>
Ah. :(

[15:32:27.0000] <TabAtkins>
Why :( ?

[15:33:46.0000] <nox>
Because I'm trying to support :matches and :not in a way that lets me compute the specificity in a clever way and it made things more difficult.


2016-03-06
[17:33:57.0000] <MikeSmith>
somebody could probably make a full-time job out of responding to stackoverflow questions from people confused by CORS

[17:34:00.0000] <MikeSmith>
http://stackoverflow.com/questions/35821855/why-is-cors-disabled-by-default

[17:34:26.0000] <MikeSmith>
but I dunno how much can or should be done in the Fetch spec itself to try to make any of it more clear

[17:35:04.0000] <MikeSmith>
I think instead that sources like MDN need to make some things more clear

[17:35:56.0000] <MikeSmith>
like, I think most developers first using CORS almost always are surprised when they find out it doesn’t send credentials by defaut

[17:38:01.0000] <MikeSmith>
so a big prominent note in MDN saying "Important: The Fetch and XHR APIs do not send credentials by default in cross-origin requests. To have them send credentials, you must…” would help

[19:22:13.0000] <rniwa>
MikeSmith

[19:22:35.0000] <rniwa>
MikeSmith: yeah, I think we need a better documentation on how cross origin security works in general

[19:22:43.0000] <rniwa>
MikeSmith: geared towards authors

[19:31:49.0000] <MikeSmith>
Yeah

[19:32:19.0000] <MikeSmith>
clearly it's non-intuitive for a lot of people

[20:11:26.0000] <terinjokes>
MikeSmith: i people i work with or help, i see a bunch of kludgey workarounds because someone didn't know how to send credentials

[20:33:50.0000] <MikeSmith>
terinjokes: so yeah it’s especially bad if the confusion causes cases like that

[21:23:24.0000] <annevk>
Workarounds might be better than security holes

[21:28:53.0000] <rniwa>
annevk: well, it would be equally bad if the workarounds was creating a new security hole though

[21:29:25.0000] <rniwa>
annevk: like... i've seen people creating JSONP to workaround same origin policy without realizing that they're just creating a security hole...

[21:29:41.0000] <rniwa>
annevk: or copying/pasting CORS headers without knowing what they mean

[21:30:00.0000] <rniwa>
annevk: because "it works" :(

[21:30:23.0000] <annevk>
Sure, I guess there is no real defense against that

[21:35:48.0000] <DocTheMedic>
hey, is this a good place to ask for "current" web design ideas?

[22:38:10.0000] <MikeSmith>
so the entirety of w3.org on the Internet seems to be down at the moment

[22:38:22.0000] <MikeSmith>
ah maybe it just now came back

[22:38:55.0000] <MikeSmith>
yeah, seems so

[22:48:51.0000] <annevk>
DocTheMedic: if you're looking for web architecture design, maybe, but web design not really

[23:01:36.0000] <DocTheMedic>
ah darn

[23:02:14.0000] <DocTheMedic>
i got the sketch, but the person wants a matrix-like website, and i'm drawing a blank on how to make it like a 2016ish website, not a 1996 website, lol

[23:02:32.0000] <DocTheMedic>
minor issue really, thanks tho

[01:47:59.0000] <annevk>
Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18242 might be worth looking at

[11:09:16.0000] <Domenic>
annevk: related https://github.com/whatwg/html/issues/473 which I still need to fix :(

[11:41:59.0000] <annevk>
Domenic: I see, that looks tough


2016-03-07
[23:20:33.0000] <rniwa>
annevk: I gotta tell you upgrading custom elements is a mess :(

[23:26:14.0000] <annevk>
rniwa: not surprised really

[23:30:44.0000] <rniwa>
annevk: I filed a whole bunch of issues on the github if you didn't see

[23:31:19.0000] <rniwa>
annevk: I think https://github.com/w3c/webcomponents/issues/421 is the most fatal one

[23:31:30.0000] <rniwa>
with https://github.com/w3c/webcomponents/issues/419 coming after that

[23:31:48.0000] <rniwa>
(along with https://github.com/w3c/webcomponents/issues/420)

[23:33:06.0000] <annevk>
I just had breakfast

[23:33:21.0000] <rniwa>
annevk: no worries, just FYI'ing

[23:34:44.0000] <annevk>
I'll get to them today

[04:05:07.0000] <Ms2ger>
zcorpan, heyo

[04:05:13.0000] <zcorpan>
hi

[04:05:36.0000] <Ms2ger>
If you feel like it at some point, https://github.com/w3c/csswg-test/pull/1060 and https://github.com/w3c/csswg-test/pull/1061

[04:06:16.0000] <annevk>
Can someone tell me where it is defined that new WebSocket("wss://example.com:80/test", { protocols:"test" }) throws?

[04:10:29.0000] <Ms2ger>
> If any of the values in protocols occur more than once or otherwise fail to match the requirements for elements that comprise the value of Sec-WebSocket-Protocol fields as defined by the WebSocket protocol specification, then throw a SyntaxError exception and abort these steps. [WSP]

[04:10:31.0000] <Ms2ger>
I guess?

[04:11:14.0000] <Ms2ger>
No idea why

[04:13:31.0000] <annevk>
Except that [WSP] defines it to be any kind of random value

[04:13:51.0000] <annevk>
As long as it meets the token production

[04:14:27.0000] <zcorpan>
annevk: step 4 or 5 of http://heycam.github.io/webidl/#es-sequence maybe?

[04:14:46.0000] <zcorpan>
the idl is [Constructor(DOMString url, optional (DOMString or sequence<DOMString>) protocols), Exposed=(Window,Worker)]

[04:14:53.0000] <zcorpan>
not dictionary

[04:15:01.0000] <annevk>
oooh doh

[04:15:50.0000] <Ms2ger>
Doh

[04:15:53.0000] <annevk>
Thanks

[04:16:22.0000] <Ms2ger>
Also, time to merge WSP back into HTML?

[04:16:50.0000] <annevk>
Ms2ger: see https://github.com/whatwg/fetch/issues/235 for some kind of intermediate solution

[04:17:06.0000] <annevk>
Ms2ger: I suppose we could put the entire protocol in Fetch, but ...

[04:17:54.0000] <annevk>
I'm working on a "monkey patch" solution at the moment, that replaces most of the client handshake section so that it shares all logic with Fetch

[04:18:13.0000] <annevk>
Solving the HSTS, Mixed Content, cookie, upgrade insecure requests, etc. problems

[04:18:29.0000] <Ms2ger>
Sounds sensible

[04:39:33.0000] <ondras>
8

[04:39:39.0000] <ondras>
oops sorry

[04:51:50.0000] <zcorpan>
someone with Edge want to test https://github.com/whatwg/html/issues/823 ?

[06:55:14.0000] <smaug____>
annevk: I'm a bit lost with https://github.com/w3c/webcomponents/issues/362

[06:55:33.0000] <annevk>
smaug____: shoot

[06:55:39.0000] <smaug____>
if the notification is only about inserted / removed from a document, why we need any params?

[06:56:57.0000] <smaug____>
ownerDocument should always tell the document, and ancestor is easy to find, especially if there is something like nodeRoot or such

[06:57:21.0000] <annevk>
smaug____: you're right about ownerDocument, that's easy enough

[06:57:41.0000] <annevk>
smaug____: there's node.rootNode now, but how does that help crossing shadow tree boundaries?

[06:58:31.0000] <smaug____>
so what is newAncestor about?

[06:58:47.0000] <smaug____>
in the node to which some other node was added as a child?

[06:58:52.0000] <smaug____>
s/in//

[06:59:15.0000] <annevk>
smaug____: "insertion steps" used to get passed "newParent", when we realized we needed to notify descendants too we made that "newAncestor"

[07:00:01.0000] <annevk>
smaug____: it's the parent of the node that had its parent node change

[07:00:16.0000] <annevk>
smaug____: same for oldAncestor in the "removing steps"

[07:00:53.0000] <annevk>
smaug____: there might not be a reason to pass either to script though, but I'm fairly certain UAs expose these internally

[07:00:56.0000] <smaug____>
do we need to notify descendants about the node to which the subtree was added?

[07:01:02.0000] <nox>
Yes.

[07:01:07.0000] <smaug____>
why?

[07:01:38.0000] <nox>
Because there are things that must be done only when you are a child of newAncestor, and some you need to do when you are unbound from the tree.

[07:01:42.0000] <annevk>
nox: note that this conversation is about the custom elements API, not the internal API, although I'm still uncertain why they need to be different

[07:02:11.0000] <smaug____>
Gecko doesn't tell to descendants to which node a subtree root was added

[07:02:35.0000] <annevk>
smaug____: and removal?

[07:03:16.0000] <nox>
annevk: Oh. I don't know anything abotu custom elements so I'll just shut up.

[07:04:31.0000] <smaug____>
annevk: same there. subtree root gets param that it has now null parent node, and descendants effectively are just notified that their ancestor chain has got shorter (something got removed from a parent)

[07:05:25.0000] <annevk>
smaug____: I see, so maybe I should change the internal API

[07:06:00.0000] <annevk>
smaug____: so that "insertion steps" only get passed newParent for the "root" and not the descendants

[07:06:09.0000] <annevk>
smaug____: and the same for "removing steps"

[07:06:51.0000] <annevk>
smaug____: that would still argue for sometimes passing newParent/oldParent to connected/disconnected, no? When they're root

[07:09:28.0000] <smaug____>
thinking

[07:10:00.0000] <smaug____>
maybe newAncestor isn't that bad. One can always check if parentNode == newAncestor and that means we're at the top of the subtree

[07:11:29.0000] <annevk>
smaug____: the main problem is that it could leak a closed shadow tree, as I pointed out there

[07:13:11.0000] <annevk>
Hmm, maybe not? If something closed has something open attached, is it still perceived as closed all the way down from the closed tree's host?

[07:14:45.0000] <annevk>
Well, that matters and it matters whether closed means just closed from where it is hosted or also closed from everything the closed thing hosts...

[07:16:52.0000] <smaug____>
what if closed (A) has something closed (B) attached. that should still work since B can see A. Closed-ness hides things only from top(root)-down

[07:18:30.0000] <annevk>
Yeah, I guess there's no problem then with closedness

[07:23:27.0000] <annevk>
smaug____: updated the issue with your feedback

[07:32:52.0000] <smaug____>
is there some easy way to make github's commenting area to work sanely when there are some <tags>s in the text?

[07:38:08.0000] <Domenic>
zcorpan: https://github.com/whatwg/html/issues/823 updated, Edge strips

[07:39:33.0000] <annevk>
smaug____: use ` and ` to escape code

[07:39:52.0000] <annevk>
smaug____: I meant, wrap code in `

[07:41:38.0000] <zcorpan>
Domenic: thanks. so currently 3 vs 1

[07:42:34.0000] <zcorpan>
Presto also strips

[07:52:01.0000] <zcorpan>
annevk: any opinion what the "trim" step should be called after dropping trimming? "parse"? "resolve"?

[07:58:23.0000] <zcorpan>
possibly this algorithm should be rewritten to not use GOTO, but don't want to do that today

[07:59:11.0000] <annevk>
zcorpan: Parse or maybe "URL" seem good

[08:00:30.0000] <zcorpan>
i'll go with parse. the string can contain "URL=" which could make URL confusing.

[08:02:06.0000] <Ms2ger>
zcorpan, https://github.com/w3c/csswg-test/pull/1061 seems ready to merge

[08:03:24.0000] <zcorpan>
Ms2ger: thx done

[08:03:32.0000] <Ms2ger>
Thank you

[09:00:32.0000] <zcorpan>
down to 0 *participating* notifications... good time to call it a day and work on my snatch

[10:02:43.0000] <annevk>
/me created a public TODO document: https://gist.github.com/annevk/4a7b51b8669c0dca4c53

[10:03:04.0000] <annevk>
Not entirely sure yet whether that's useful, but if anyone has feedback, most welcome

[10:38:25.0000] <TabAtkins>
MikeSmith, annevk: I've found it useful to add explainer sections to some of my specs for complicated bits, giving some explanation and examples of common usage.  Flex and Grid both have them, for example.  Would probably be useful in Fetch.

[11:34:13.0000] <zcorpan>
TabAtkins: re https://github.com/whatwg/html/issues/807#issuecomment-193405543 it's (for not-gigantic files) simpler than that; just click "edit", it seamlessly creates a fork and a new branch and gives you a "make a PR" button

[11:34:35.0000] <TabAtkins>
Ah, indeed.

[12:42:41.0000] <Jasper>
I often see URIs on the web which contain Unicode characters in them, which is wrong. I know the typical thing to do is to UTF-8-encode them and then urlencode on the results, but is there any specification for that?

[12:42:57.0000] <Jasper>
Or is the behavior of Firefox, e.g. more complicated?

[12:56:10.0000] <annevk>
Jasper: https://url.spec.whatwg.org/

[12:57:03.0000] <Jasper>
I thought I had a cursory look at that and didn't find anything

[12:57:04.0000] <Jasper>
/me looks closer

[12:58:28.0000] <annevk>
Jasper: what you mentioned is approximately what happens for path and query components

[12:59:10.0000] <annevk>
Jasper: host has IDNA handling, fragment might leave things as-is atm

[12:59:47.0000] <annevk>
Jasper: URL parser defines the details


2016-03-08
[20:16:40.0000] <MikeSmith>
TabAtkins: yeah I agree it would help for Fetch to have an explainer section. I guess I can make an attempt to write one myself if nobody else beats me to it

[23:51:39.0000] <annevk>
MikeSmith: TabAtkins: I missed the context for this, but I agree Fetch could use more language here

[23:52:12.0000] <annevk>
MikeSmith: TabAtkins: I always find it a little hard to justify working on such things while there's still a ton of incorrect implementer language around

[00:14:02.0000] <annevk>
I have a hard time not reading https://github.com/whatwg/dom/issues/102 as "Make Attr great again"

[03:29:52.0000] <nox>
annevk: That issue makes me very sad. :(

[03:58:08.0000] <zcorpan>
can we also disable features when document.write is used? :-D

[04:05:54.0000] <jgraham>
maybe we could just disable loading webpages when document.write is used :)

[04:06:27.0000] <jgraham>
Although the servo people claim that not supporting document.write is a zero-cost ad-blocker

[04:06:34.0000] <jgraham>
(this is not really true)

[06:21:18.0000] <smaug____>
ok, so I wonder how many specs are now inconsistent with http://w3c.github.io/webappsec-mixed-content/ :/

[06:21:23.0000] <smaug____>
this is a great mess atm

[06:21:26.0000] <smaug____>
oh well

[06:21:35.0000] <smaug____>
such is life :)

[06:22:23.0000] <MikeSmith>
solution: just set Content-Security-Policy: upgrade-insecure-requests and forget it

[06:23:36.0000] <annevk>
smaug____: only WebSocket is

[06:23:53.0000] <annevk>
smaug____: everything else should route through Fetch already which dispatches to that specification

[06:24:09.0000] <smaug____>
one day I'll read Fetch spec

[06:24:14.0000] <annevk>
smaug____: soon WebSocket will also route through Fetch and things will be wonderful

[06:24:32.0000] <annevk>
maybe not wonderful, but slightly better anyway

[06:24:42.0000] <smaug____>
so how is http://w3c.github.io/webappsec-mixed-content/ related to this all then?

[06:25:31.0000] <annevk>
smaug____: Fetch uses that specification to define the Mixed Content check

[06:25:54.0000] <annevk>
smaug____: step 5 of https://fetch.spec.whatwg.org/#main-fetch

[06:26:36.0000] <MikeSmith>
/me misunderstood; thought smaug____ was talking about the resources of the spec source

[06:28:17.0000] <smaug____>
MikeSmith: nah, just trying to figure out how many specs I need to review before reviewing a patch.

[06:28:22.0000] <smaug____>
looks like 3

[06:41:12.0000] <MikeSmith>
well that seems manageable

[06:47:05.0000] <annevk>
zcorpan_: if you want I can introduce such a default User-Agent value concept now

[06:47:19.0000] <annevk>
zcorpan_: I mean, I'll do it unless you see a problem

[06:47:25.0000] <zcorpan_>
annevk: sure

[06:47:32.0000] <MikeSmith>
today’s SO question where somebody had a problem that turned out to be due just to them not knowing that Fetch doesn’t send credentials by default http://stackoverflow.com/questions/35868312/django-1-9-ajax-form-csrf-token-403-error-csrf-cookie-not-set/35869947#35869947

[06:48:19.0000] <annevk>
MikeSmith: yeah, this safe default is tripping up many folks

[06:48:48.0000] <annevk>
MikeSmith: maybe I should've used XHR's default... so little feedback during the development of that API

[06:50:46.0000] <MikeSmith>
annevk: I think partly it just takes time for it to enter into the collective developer consciousness

[06:51:22.0000] <MikeSmith>
I mean, there are many more arcane/esoteric things about the platform that developers just sorta know

[06:51:35.0000] <annevk>
MikeSmith: hopefully, I know Mark Miller will be pleased with this default, although not everyone will see that as a good sign

[07:41:20.0000] <Ms2ger>
annevk, what's the "local-URLs-only flag" for?

[07:42:33.0000] <annevk>
Ms2ger: CSS/SVG

[07:43:27.0000] <annevk>
Ms2ger: they haven't really defined their fetching model yet, though, but this is what I think they'll need to define "SVG as image" and "SVG as gradient" and such

[07:43:48.0000] <annevk>
Ms2ger: although maybe they're a little closer now, but nothing to the level of detail I'd like

[07:43:50.0000] <Ms2ger>
I see, thanks

[07:45:33.0000] <Ms2ger>
annevk, is there a reason not to return the network error in step 2 of https://fetch.spec.whatwg.org/#concept-main-fetch ?

[07:52:51.0000] <annevk>
Ms2ger: yeah, async callers wouldn't know what happened

[07:53:57.0000] <Ms2ger>
Still trying to figure the control flow here

[07:55:14.0000] <annevk>
Ms2ger: main fetch returns for recursive and synchronous invocations; for async it ends up queuing stuff in the end

[07:56:22.0000] <annevk>
Ms2ger: it's not the best and I've tried to get input on the design, but as with most things I write I'm kinda left to figure it out on my own

[07:56:37.0000] <Ms2ger>
Yeah

[07:56:39.0000] <annevk>
Ms2ger: not sure if that's due to me or simply a result of the problems I tackle not being super interesting to others

[07:57:20.0000] <Ms2ger>
Or designing stuff like this being Hard(TM) :)

[07:58:40.0000] <annevk>
wanderview: oooh I see

[07:58:48.0000] <annevk>
wanderview: you'd wait all the way until the network

[07:58:58.0000] <wanderview>
yea, that was the idea

[07:59:04.0000] <wanderview>
try to make all the credential stuff work the same

[07:59:08.0000] <annevk>
wanderview: network or cache API?

[07:59:25.0000] <annevk>
wanderview: otherwise you're in trouble offline

[07:59:43.0000] <wanderview>
well, cookies don't go in cache API requests now

[07:59:53.0000] <annevk>
wanderview: no, but they get stored somewhere

[08:00:13.0000] <annevk>
wanderview: I guess these get stored too someplace

[08:00:14.0000] <wanderview>
I would have to think about Cache a bit

[08:00:29.0000] <annevk>
it might be fine, given that there is a credential store

[08:00:41.0000] <wanderview>
annevk: yea, but the cookie connection to the Request is automatic... here script is attaching the Credential object

[08:01:05.0000] <wanderview>
and that association of the Credential to Request should happen at constructor time

[08:01:10.0000] <annevk>
I think you might still want to pass it to request somehow and request might want to identify it will get those things attached

[08:01:16.0000] <annevk>
yeah

[08:01:39.0000] <annevk>
but it sorta makes sense to not do it straight away to avoid a bunch of the pitfalls

[08:01:44.0000] <wanderview>
annevk: I'll write some github issues this afternoon so mikewest can see them

[08:01:59.0000] <annevk>
sounds good

[08:43:04.0000] <Domenic>
annevk: want to wait for another look from aklein or shall I sanity-check compile and merge the structured clone fix?

[09:13:09.0000] <annevk>
Domenic: happy to wait

[09:36:55.0000] <Domenic>
annevk: turned out "create an element" was a really good idea, if only for deduping code between createElement and createElementNS. So yay.

[09:37:33.0000] <annevk>
Yay abstractions

[09:40:59.0000] <wanderview>
annevk: https://github.com/w3c/webappsec-credential-management/issues/11

[10:08:04.0000] <Domenic>
Why are we passing attribute namespace to attributeChangedCallback. It's so useless.

[10:30:09.0000] <smaug____>
Domenic: consistency with MutationObserver?

[10:30:14.0000] <smaug____>
just a guess

[10:36:05.0000] <Domenic>
smaug____: seems legit

[11:40:37.0000] <aklein>
Domenic, annevk: structured clone fix looks good now

[12:30:26.0000] <annevk>
aklein: ta, landed

[12:31:03.0000] <annevk>
aklein: I guess now we can work on the serialize/deserialize rewrite -_-

[12:50:58.0000] <wanderview>
/me writes the promise-returning withFrame(url) function a lot too...

[14:23:51.0000] <Domenic>
Starting to feel like the custom elements spec is something we can be proud of...

[14:24:04.0000] <Domenic>
Big remaining issues are nanotasks and parser

[14:26:04.0000] <Domenic>
https://github.com/w3c/webcomponents/issues/412#issuecomment-193935169 is also interesting, should be pretty easy once we figure out what we want though


2016-03-09
[16:30:31.0000] <caitp>
does anyone know where that spec about same-origin security went? I thought it got put on github on the whatwg org, but I don't see it

[16:33:27.0000] <caitp>
whatever it was called, that thing that used to be just an etherpad

[16:37:17.0000] <caitp>
god why is it impossible to find frigging anything :<

[16:42:40.0000] <caitp>
https://github.com/annevk/html-cross-origin-objects this thing --- y'all should move that to an actual org sometime so it's easier to find @_@

[17:26:27.0000] <Domenic>
caitp: it's in the actual spec now

[17:26:33.0000] <Domenic>
annevk: you should gut that repo

[17:27:13.0000] <caitp>
eh, it's even harder to find things in the html spec, I dunno how you guys deal with it

[17:27:28.0000] <Domenic>
caitp: https://html.spec.whatwg.org/#cross-origin-objects + https://html.spec.whatwg.org/#the-windowproxy-exotic-object + https://html.spec.whatwg.org/#the-location-interface

[17:27:39.0000] <Domenic>
singlepage plus Ctrl+F gets you pretty far

[17:27:51.0000] <caitp>
on a laptop? takes forever :p

[17:27:55.0000] <caitp>
even worse on a phone

[17:39:19.0000] <caitp>
hmm, so you guys made Window not array-like by moving the indexed property access stuff to WindowProxy to escape the rules of webidl? o_o

[17:46:33.0000] <Domenic>
I believe so that Window could become a non exotic object

[17:46:49.0000] <Domenic>
Also because of something about navigation and cross origin indexed access

[00:32:57.0000] <annevk>
Domenic: it says right at the top that it's obsolete

[00:42:08.0000] <mkwst>
annevk: How does Anolis resolve references to documents? Like, what do I need to poke to get the credential management thing into a list that it can resolve?

[00:42:14.0000] <mkwst>
(Also, good morning!)

[00:42:42.0000] <annevk>
mkwst: morning, you need to have https://github.com/whatwg/xref/ in parallel dir

[00:43:33.0000] <mkwst>
annevk: I do. I guess I need to send a PR there, thanks!

[00:44:15.0000] <annevk>
mkwst: I can give you commit access

[00:44:36.0000] <mkwst>
Ok. I'd still ask you to review a PR. :)

[00:44:40.0000] <annevk>
ok

[00:44:51.0000] <mkwst>
just to make sure I understand how it works.

[00:47:57.0000] <Ms2ger>
/me sticks his head up

[00:48:04.0000] <Ms2ger>
Who's still using anolis?

[00:48:23.0000] <Ms2ger>
/me is starting to understand why Windows XP is still everywhere

[00:53:17.0000] <zcorpan>
Ms2ger: so how do i get anolis to run on XP??

[00:53:37.0000] <Ms2ger>
You'd better send me chocolate...

[00:53:48.0000] <zcorpan>
:-)

[00:55:25.0000] <annevk>
Given your respective living locations, I'd expect chocolates to move in the other direction

[00:56:55.0000] <Ms2ger>
And they historically have

[00:58:30.0000] <annevk>
Must be a great many Anolis on Windows XP users for that to have changed

[01:23:00.0000] <zcorpan>
why doesn't https://html.spec.whatwg.org/#dom-option-text just use the child Text nodes??

[01:25:31.0000] <annevk>
zcorpan: topic?

[01:26:44.0000] <zcorpan>
annevk: i'm introducing the "child text content" concept for <title>.text, <script>, <style>, <time>, etc., and i found <option>.text doing this weird thing (which seems to be implemented in webkit/blink/gecko)

[01:35:42.0000] <Ms2ger>
zcorpan, is that the skipping script thing?

[01:42:39.0000] <annevk>
zcorpan: heh

[01:48:06.0000] <zcorpan>
Ms2ger: yeah. now found https://www.w3.org/Bugs/Public/show_bug.cgi?id=19549 https://github.com/whatwg/html/commit/b1adc35035eff05e6177d11cc5e564934a0cc977

[01:49:10.0000] <Ms2ger>
On the plus side, there's a bunch of tests

[01:53:24.0000] <zcorpan>
yeah, i'm not going to try to change this one

[07:17:00.0000] <annevk>
Domenic: philipj_: MikeSmith: shall we adopt an "Editorial:" policy? That commits that are editorial start with that in their title

[07:17:14.0000] <annevk>
Makes it easier to filter the log

[07:17:50.0000] <annevk>
TC39 does this and it seems rather nice (not all is perfect there btw, they also use the repo for the spec for a ton of other things)

[07:24:43.0000] <annevk>
I'm glad there's at least one group maintaining HTML that does seek outside input since this is rather dreadful: https://github.com/w3c/html/pull/144

[07:25:14.0000] <annevk>
I thought the whole pitch was that the W3C had "due process"

[07:36:20.0000] <MikeSmith>
annevk: OK by me but I wonder if we could abbreviate it, given that git wants to limit the first like of the description to 50 chars

[07:40:29.0000] <annevk>
MikeSmith: maybe, it seems better to be able to tell it's editorial quickly and if it's a big change you can elaborate in the body

[07:40:45.0000] <MikeSmith>
ok

[07:40:49.0000] <MikeSmith>
yeah, makes sense

[07:41:15.0000] <gsnedders>
Ed: foo?

[07:42:05.0000] <MikeSmith>
“✏️ Fixed typo in previous commit”

[07:43:51.0000] <MikeSmith>
anyway I now realize I really liked the way that the old commit-log viewer grayed out all the editorial commits

[08:28:32.0000] <wanderview>
JakeA: do you have an opinion about my Cache API questions here? https://github.com/w3c/webappsec-credential-management/issues/11

[08:32:32.0000] <JakeA>
wanderview: thanks for the heads up, will give it a proper read

[08:32:41.0000] <wanderview>
thanks

[08:42:08.0000] <wanderview>
annevk: does the websocket integration with fetch allow any interception by service workers?  #lazyirc

[08:44:41.0000] <annevk>
wanderview: it sets the skip-service-worker flag

[08:45:04.0000] <wanderview>
annevk: ok, thanks!

[09:07:45.0000] <annevk>
wanderview: if we ever did WebSocket it would have its own event I think

[09:07:53.0000] <annevk>
wanderview: WebSocket in service workers, that is

[09:08:14.0000] <wanderview>
cool

[09:08:15.0000] <annevk>
wanderview: but I don't think there's a real need for that given postMessage() protocols and such

[09:08:51.0000] <wanderview>
yea, WebSocket and service workers needs thought... just wanted to make sure I hadn't missed it in case I needed to write an "implement this" bug on gecko

[09:10:27.0000] <annevk>
The main reason this is done is so that WebSocket doesn't miss out on all the security hooks that Fetch has

[09:10:42.0000] <annevk>
As a bonus it also defines cookie handling better

[09:11:24.0000] <Domenic>
annevk: sure but I think just gutting it like I did https://github.com/whatwg/meta-theme-color would be better. Old commits are still there.

[09:12:59.0000] <Domenic>
annevk: "Editorial: " prefix seems reasonable to me, although the line can be pretty fuzzy sometimes. I guess we should add a tag that we tag PRs with so people remember.

[09:15:23.0000] <annevk>
Domenic: removed more content from it

[09:21:08.0000] <Domenic>
👍

[10:37:54.0000] <jsbell>
MikeSmith: while I'm not (yet) volunteering to edit FileAPI (still trying to find someone), can you anoint me ('inexorabletash') with appropriate powers to triage/label the open issues?

[10:46:34.0000] <MikeSmith>
jsbell: will do

[10:46:44.0000] <MikeSmith>
gimme a moment

[10:49:30.0000] <MikeSmith>
k

[10:49:39.0000] <MikeSmith>
jsbell: should be done now

[10:51:16.0000] <jsbell>
MikeSmith: thx. Hasn't appeared yet but perhaps it takes a bit.

[10:54:16.0000] <MikeSmith>
no should be immediate

[10:54:19.0000] <MikeSmith>
/me re-checks

[10:55:29.0000] <MikeSmith>
oops

[10:55:38.0000] <MikeSmith>
yeah my mistake

[10:55:40.0000] <MikeSmith>
fixed now

[10:55:56.0000] <MikeSmith>
jsbell:

[10:56:03.0000] <MikeSmith>
jsbell: ⬆

[10:56:08.0000] <jsbell>
MikeSmith: confirmed - thx!

[10:57:30.0000] <MikeSmith>
super

[12:18:23.0000] <TabAtkins>
Domenic: Watching your WebDir talk, and I *cannot stop* hearing you saying "async Perl".

[14:39:09.0000] <rniwa>
annevk, smaug____: W3C tests for rootNode at https://github.com/w3c/web-platform-tests/pull/2665

[14:39:52.0000] <smaug____>
jgraham: you're going to merge those soon, right ;)

[14:40:01.0000] <smaug____>
I mean to mozilla-inbound

[14:42:08.0000] <jgraham>
smaug____: Well if someone reviews them and merges them to wpt, sure

[14:42:50.0000] <gsnedders>
http://news.mit.edu/2016/system-loads-web%20pages-34-percent-faster-0309

[14:46:00.0000] <jgraham>
I read that whole article and I still have no idea what they did

[14:53:53.0000] <gsnedders>
jgraham: yeah. I hope more gets said at conference and published thereafter

[14:54:18.0000] <MikeSmith>
what conference?

[14:57:19.0000] <tantek>
the Web Hypertext Application Technologies conference?

[15:01:21.0000] <gsnedders>
MikeSmith: "he will present at this week’s USENIX Symposium on Networked Systems Design and Implementation"

[15:01:54.0000] <MikeSmith>
ah ok

[15:02:45.0000] <MikeSmith>
well, big deal :) nobody’s ever heard of that

[15:03:07.0000] <MikeSmith>
seriously it looks promising if true

[15:03:24.0000] <MikeSmith>
tantek: the Web Hypertext Application Technologies conference is what we got here every day 😆

[15:03:59.0000] <MikeSmith>
the longest-running conference on the Web runtime and security model and feature set

[15:03:59.0000] <tantek>
nah, we have more like a Web Hypertext Application Technologies webinar, watched through Lynx

[15:04:05.0000] <MikeSmith>
hahah

[15:04:10.0000] <MikeSmith>
fair enough

[15:04:50.0000] <tantek>
seriously would be amazing for there to be a Web Hypertext Application Technologies conference, especially if we could convince Hixie to keynote


2016-03-10
[16:09:02.0000] <Domenic>
I believe the proper term is Web Hypertext Application Technologies Un-Plenary

[16:09:24.0000] <Domenic>
wait no it was Unconference Plenary

[16:33:21.0000] <tantek>
Domenic++

[16:33:57.0000] <TabAtkins>
+1

[21:55:57.0000] <annevk>
rniwa++ for tests

[22:03:40.0000] <rniwa>
annevk: :)

[22:03:54.0000] <rniwa>
annevk: i've got a few dozens of tests for shadow DOM and custom elements now:

[22:04:23.0000] <rniwa>
https://github.com/WebKit/webkit/tree/master/LayoutTests/fast/shadow-dom

[22:04:27.0000] <rniwa>
https://github.com/WebKit/webkit/tree/master/LayoutTests/fast/custom-elements

[22:35:28.0000] <philipj_>
annevk: I don't like having prefixes to the commit messages, it uses up valuable space. So I'm also not a fan of "Fix #100:" and like to put this in the description

[01:46:52.0000] <rniwa>
Domenic: yt?

[01:53:12.0000] <annevk>
rniwa: it's nearly 5AM if he isn't traveling

[02:03:28.0000] <zcorpan>
mutation events :-| ... https://www.chromestatus.com/metrics/feature/timeline/popularity/144 at least it's going down

[02:05:39.0000] <annevk>
I'm hoping esprehn can change the timing of mutation events

[02:05:53.0000] <annevk>
If that's feasible we should just add them to the standard and forget about them

[02:14:28.0000] <annevk>
Looks like I'm going to standardize port banning today 😃

[02:14:55.0000] <zcorpan>
https://www.chromestatus.com/metrics/feature/timeline/popularity/146 DOMNodeRemovedFromDocument is at 0.0086% now

[02:29:17.0000] <smaug____>
Hmm, there was some discussion about hitregions in some github bug recently... anyone happen to recall which bug it was

[02:29:23.0000] <smaug____>
not https://github.com/whatwg/html/issues/849 but some other

[02:29:59.0000] <smaug____>
(and could we move issue tracking back to some bugzilla instance)

[02:31:14.0000] <zcorpan>
miketaylr: fyi https://lists.w3.org/Archives/Public/www-style/2016Feb/0169.html

[02:32:29.0000] <smaug____>
ok, found it. https://github.com/whatwg/html/issues/548

[03:19:21.0000] <annevk>
smaug____: we cannot, we migrated away from Bugzilla

[03:25:56.0000] <annevk>
smaug____: so your suggestion for hit regions is to make the hit region object (is there such a thing?) inherit from EventTarget?

[03:26:02.0000] <annevk>
smaug____: seems somewhat reasonable

[03:26:21.0000] <annevk>
smaug____: would its "get the parent" return the <canvas> it's associated with?

[03:28:19.0000] <smaug____>
I don't think I suggested that

[03:31:45.0000] <smaug____>
annevk: I'm talking more about these steps: "Let control be the control represented by region for this canvas element, if any." ... "If there is a control, then target the event object at control instead of the canvas element."

[03:32:09.0000] <smaug____>
so we already dispatch the event on the "hit region control"

[03:32:31.0000] <smaug____>
and event.region == event.target.id

[03:32:49.0000] <smaug____>
or something like that

[03:33:43.0000] <annevk>
Seems indeed redundant then

[03:34:59.0000] <smaug____>
but Touch handling is something different

[03:36:06.0000] <smaug____>
but I think mostly the whole .region stuff is busted.

[03:36:37.0000] <smaug____>
whoever designed the API could explain why it is the way it is

[03:37:02.0000] <annevk>
I think Hixie_ designed it

[05:05:25.0000] <zcorpan>
annevk: random thought: it seems slightly weird to have "should" in a defined term

[05:12:13.0000] <Ms2ger>
mix and csp do the same

[05:37:11.0000] <zcorpan>
i see Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits as a request header in opera

[05:39:14.0000] <zcorpan>
and .extensions returns "permessage-deflate"

[06:08:34.0000] <annevk>
zcorpan: that is weird

[06:08:42.0000] <annevk>
zcorpan: ugh

[06:09:23.0000] <annevk>
zcorpan: file an issue? That requires a bunch of changes to various drafts

[06:09:45.0000] <zcorpan>
ok

[06:41:08.0000] <annevk>
zcorpan: did you work on WebSocket tests?

[06:41:20.0000] <annevk>
zcorpan: the README doesn't really say where to find server code

[06:41:59.0000] <wanderview>
annevk: step 29 here seems to allow HEAD no-cors requests... https://fetch.spec.whatwg.org/#dom-request

[06:42:00.0000] <zcorpan>
annevk: i did, yeah. the server code is pywebsocket i believe

[06:42:31.0000] <Ms2ger>
Yep

[06:42:48.0000] <annevk>
zcorpan: did you test protocols not matching?

[06:42:57.0000] <annevk>
zcorpan: and where do I find that code in relation to the tests?

[06:43:09.0000] <annevk>
wanderview: hmm, I wonder if that's accurate

[06:43:13.0000] <zcorpan>
annevk: trying to find a test that tests the removed protocols thing, but little luck so far

[06:43:27.0000] <annevk>
wanderview: afaict there's not a single feature on the web that can do HEAD across origins

[06:43:37.0000] <wanderview>
annevk: why is it bad?  if it ends up going to a same-origni you can see status... if you end up going cross-origin you see 0 status

[06:43:40.0000] <zcorpan>
annevk: the handlers are in websockets/handlers/

[06:43:48.0000] <annevk>
wanderview: even if we did allow HEAD though, that doesn't mean cache should be able to modify opaque responses

[06:44:14.0000] <wanderview>
annevk: at Request constructor time you don't know if you will get an opaque response or not if you fetch() it

[06:45:00.0000] <wanderview>
annevk: where is the failure for doing the HEAD request cross-origin?

[06:45:52.0000] <zcorpan>
annevk: hmm here we have something ./constructor/012.html:  var ws = new WebSocket(SCHEME_DOMAIN_PORT+'/handshake_no_protocol', 'foobar');

[06:46:18.0000] <annevk>
wanderview: I'm saying there might be a bug in Fetch that we allow that, or maybe we decided on allowing it since nobody thought it could do harm

[06:46:26.0000] <annevk>
wanderview: I'm vaguely remembering it might be the latter

[06:46:36.0000] <annevk>
wanderview: but that still doesn't mean you should be able to modify an opaque response

[06:47:22.0000] <wanderview>
annevk: the browser can clearly modify opaque responses and does whenever it sets the bodyUsed by internally draining

[06:48:00.0000] <wanderview>
annevk: the cache spec is generally problematic here, though, because it does not serialize and deserialize the Response... so it looks like it just has a list of Response objects... its really creating a new one each time it returns

[06:48:17.0000] <annevk>
zcorpan: contents of handshake_no_protocol_wsh.py are a little weird

[06:48:57.0000] <zcorpan>
annevk: yeah, it's a hack due to limitations of pywebsocket (or limited understanding) at the time the tests were written

[06:54:10.0000] <annevk>
zcorpan: thanks

[06:54:17.0000] <wanderview>
annevk: so we don't think we will ever want to send a password credential without cookies?

[06:55:11.0000] <annevk>
wanderview: it doesn't seem great to let developers modify opaque responses, although I'd have to page everything in again as to why that might be problematic

[06:55:23.0000] <annevk>
wanderview: well, that's what mkwst thinks

[06:55:43.0000] <wanderview>
oh, that's mkwst's irc handle!  I kept looking for him here

[06:55:44.0000] <annevk>
wanderview: I raised that point in the PR

[06:56:45.0000] <wanderview>
yea

[07:00:08.0000] <annevk>
Domenic: https://github.com/whatwg/html/pull/840 all good now or still wary?

[07:00:57.0000] <wanderview>
HTML seems particularly hostile to diff reviewing for some reason

[07:01:10.0000] <zcorpan>
annevk: just added a comment

[07:33:41.0000] <annevk>
zcorpan: thanks, so how about I add a check in Fetch

[07:33:57.0000] <zcorpan>
annevk: wfm

[07:34:24.0000] <annevk>
zcorpan: "If _protocols_ is not the empty list and _response_'s header list does not contain a header named Set-WebSocket-Protocol, then fail the WebSocket connection"

[07:37:03.0000] <zcorpan>
annevk: also check if the header is present but doesn't contain any value

[07:38:00.0000] <zcorpan>
(havne't tested that but it seems it should be equivalent to omitting the header)

[07:48:38.0000] <annevk>
zcorpan: https://github.com/whatwg/fetch/pull/242

[07:53:59.0000] <zcorpan>
r+; need to leave now

[08:21:32.0000] <mkwst>
wanderview: Hi, sorry. Wasn't looking at IRC.

[08:21:44.0000] <wanderview>
not a problem

[08:21:51.0000] <mkwst>
wanderview: No, I don't think it makes sense to separate this kind of credential from any of the other kinds of credentials Fetch already deals with.

[08:22:07.0000] <wanderview>
yea, sorry... I finally found the discussion in the PR

[08:22:23.0000] <mkwst>
That is, if I'm trying to authenticate a session, I'm going to want to manage HTTP state along with the authentication information I'm sending over.

[08:23:29.0000] <mkwst>
(and sorry about the IRC handle. It seemed like a BRILLIANT idea in the heady, vowelless days of Web 2.0.)

[08:35:13.0000] <Ms2ger>
Pff, even I have a vowel

[08:48:56.0000] <Ms2ger>
/me realizes he's had this name for over a decade now

[09:59:58.0000] <gabr13l>
o/ WHATWG crew

[10:00:12.0000] <gabr13l>
/me used to be cgcardona FWIW

[10:05:57.0000] <annevk>
gabr13l: good evening

[10:06:10.0000] <gabr13l>
hi annevk

[10:30:06.0000] <wanderview>
mkwst: btw, I'm still concerned about Matt's feedback here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ

[10:30:27.0000] <wanderview>
mkwst: I'm asking the person interested in implementing the spec in gecko to post to dev-platform so we can come to some concensus within mozilla

[10:52:34.0000] <MikeSmith>
hey gabr13l

[10:52:46.0000] <gabr13l>
hi MikeSmith

[10:56:57.0000] <smaug____>
annevk: trying to understand why people are against the 4th param version of addEventListener

[10:57:02.0000] <smaug____>
any new arguments ?

[10:57:08.0000] <smaug____>
other than "I don't like it"

[10:57:47.0000] <smaug____>
the API happens to be so commonly used that we need to be _very_ careful with all the compatibility issues

[10:58:07.0000] <smaug____>
and 4th param approach should be safer than 3rd param approach

[10:58:53.0000] <smaug____>
(and I'd really prefer if we spent less time on this and more time on designing some new way to add listeners)

[10:59:04.0000] <smaug____>
(since I assume that will take several months to get right)

[11:56:03.0000] <TabAtkins>
smaug____: If we can *actually commit* to doing that, and not just (as I expect) say "Yeah, we'll fix this in a new API" and then never develop it, then I'm okay with the stupid 4th-arg approach.

[11:56:48.0000] <TabAtkins>
I'm just pretty sure that no one will actually spend the time to design a new API, or if they do, it'll get shot down as not worth the implementation effort for a minor usability benefit.

[11:57:03.0000] <TabAtkins>
See: what has happened with createElement for the last several years.

[11:58:25.0000] <smaug____>
what has happened with createElement?

[11:58:36.0000] <smaug____>
it hasn't really changed

[11:58:40.0000] <smaug____>
this way radically

[12:00:05.0000] <TabAtkins>
People keep asking for a *usable* version of it, that lets you set attributes/properties/children.

[12:00:25.0000] <TabAtkins>
What every single DOM wrapper library provides, because the current DOM API is really terrible in usability.

[12:00:52.0000] <TabAtkins>
(I have one in Bikeshed - E.h1({attrs}, children...), for example.)

[12:01:18.0000] <TabAtkins>
But even tho the ideas get well-developed, no impls ever bite, because it doesn't actually provide anything *new*.

[12:01:58.0000] <TabAtkins>
And afaik, the same is true of a better-designed event-listener API - it's just "more usable", not "new functionality".

[12:02:15.0000] <TabAtkins>
/me is heading to lunch

[12:36:00.0000] <rbyers>
TabAtkins: if you or annevk or someone can commit to getting a new API into the spec, I'm happy to commit to implementing and shipping it in blink.

[12:41:13.0000] <Domenic>
rbyers: TabAtkins: annevk: https://github.com/straker/html-tagged-template/ looks like the best bet for me

[12:41:35.0000] <Domenic>
(modulo https://github.com/straker/html-tagged-template/issues/6 )

[12:45:53.0000] <annevk>
Domenic: I think he meant a better event listener API

[12:46:03.0000] <Domenic>
ah, right, that would make sense :P

[12:46:30.0000] <annevk>
smaug____: there is no backcompat issue

[12:47:57.0000] <rbyers>
annevk: I talked a bit with smaug offline, it's all the Firefox ESR users (9-12 months old) that he's worried about - so forwards compat, but not back compat.

[12:48:40.0000] <rbyers>
.. that said, it's still possible there's a back compat issue - we just haven't found any concrete examples yet (and it's now in Chrome stable, so if there are a non-trivial number we should hear soon).

[12:50:21.0000] <annevk>
Those users will be in trouble anyway with each attractive new feature

[12:50:53.0000] <smaug____>
addEventListener is very different thing than some new attractive feature

[12:51:37.0000] <annevk>
This API will be around much longer than twelve months, it's important to do right by it

[12:52:36.0000] <smaug____>
and hacking 3rd param isn't more correct than 4th param approach. The 4th param approach is even less hacky since it doesn't add this bizarre boolean or dictionary thing

[12:52:45.0000] <smaug____>
this is of course very subjective

[12:55:31.0000] <smaug____>
/me wonders what cloneRecord.[[TransferList]] means

[12:55:34.0000] <smaug____>
in the spec

[13:11:23.0000] <Domenic>
Am I not following enough links or is XHTML parsing rather under-defined

[13:11:33.0000] <Domenic>
Like where does it say for XHTML that <a> tags -> HTMLAnchorElement and such

[13:16:03.0000] <zcorpan>
Domenic: it's under-defined. there's no spec for how to turn an XML byte stream into a DOM at all.

[13:17:58.0000] <Domenic>
/me flips some tables

[13:19:51.0000] <zcorpan>
iirc there's Infoset that defines a mapping for the Infoset, but there's no explicit mapping between Infoset and DOM

[13:22:13.0000] <zcorpan>
fun fact: https://www.w3.org/TR/xml-stylesheet/ is defined in terms of Infoset

[13:26:01.0000] <gsnedders>
zcorpan: as is XPath and XSLT

[14:52:04.0000] <JonathanNeal>
Should a <picture> element display like an <img>? In that it’s an inline element that behaves like an inline-block element?

[14:56:31.0000] <zcorpan>
JonathanNeal: no <picture> displays like a <span>

[14:57:02.0000] <zcorpan>
it's the child <img> that shows the image

[14:59:00.0000] <JonathanNeal>
@zcorpan, this is the expected result? http://codepen.io/anon/pen/KzMmyX

[14:59:58.0000] <zcorpan>
JonathanNeal: yes

[15:01:32.0000] <zcorpan>
JonathanNeal: you can style the <img> as usual

[15:01:53.0000] <zcorpan>
HTH

[15:01:58.0000] <zcorpan>
/me -> bed


2016-03-11
[17:31:51.0000] <spring2>
hi i need help about learning queueing for 2 different div id loading on document .ready

[17:31:52.0000] <spring2>
anyone want to help me plz  thx

[18:04:40.0000] <karlcow>
Should we fix that? https://github.com/webcompat/web-bugs/issues/2344#issuecomment-195141744

[18:04:48.0000] <karlcow>
window.location.replace('');

[18:13:33.0000] <karlcow>
Blink (Opera), Firefox (Gecko) enters an infinite loop

[20:05:20.0000] <rniwa>
hayato: yt?

[20:05:36.0000] <rniwa>
Domenic: yt?

[20:05:38.0000] <hayato>
rniwa: yeah

[20:05:38.0000] <rniwa>
annevk: yt?

[20:05:48.0000] <rniwa>
hayato: what was your intention on https://github.com/w3c/webcomponents/issues/432 ?

[20:08:16.0000] <hayato>
rniwa: I guess the spec should clarify a case where event target is not a Node.

[20:08:26.0000] <rniwa>
hayato: indeed.

[20:10:59.0000] <hayato>
There was no intention. So deepPath() should return *eventPath*, a list of event targets, even if event target is a not Node. We should clarify it.

[20:13:49.0000] <rniwa>
hayato: okay, so you want to include it in the path?

[20:14:17.0000] <hayato>
Hmm. I have not considered it seriously so far...

[20:14:20.0000] <rniwa>
hayato: what if the path included a Node but the current target didn't?

[20:14:40.0000] <rniwa>
hayato: we can't quite determine whether a Node should be unclosed in that case

[20:15:07.0000] <rniwa>
hayato: so it seems that we may need to return an empty array in that case

[20:15:20.0000] <rniwa>
hayato: and most of non-Node targets don't have anything to bubble up (e.g. XHR)

[20:15:52.0000] <rniwa>
so I can't think of a use case in which deepPath() is needed

[20:16:29.0000] <hayato>
Yeah, for a world of non-node-tree, we can have a different answer.

[20:17:04.0000] <hayato>
Could you share a concrete example in the issue?

[20:17:17.0000] <hayato>
Let me think about it.

[20:17:27.0000] <rniwa>
hayato: I can't think of a concrete case in which this is possible

[20:17:34.0000] <rniwa>
so it could be a non-issue.

[20:17:42.0000] <rniwa>
I'm hoping that annevk can give us an insight into this

[20:18:01.0000] <hayato>
I see.

[20:22:20.0000] <rniwa>
hayato: writing a test for deepPath() is such a labor intensive work :(

[20:22:38.0000] <rniwa>
hayato: do you guys have a test for it somewhere?

[20:24:50.0000] <hayato>
Only in LayoutTests of Blink, I guess

[20:24:57.0000] <hayato>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/fast/dom/shadow/

[20:25:01.0000] <hayato>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/shadow-dom/

[20:25:50.0000] <rniwa>
hayato: cool!

[20:26:00.0000] <hayato>
However, I have not  written any test for event.deepPath() for non-node-tree.

[20:26:10.0000] <rniwa>
hayato: I guess /dom/shadow is for v0?

[20:26:18.0000] <rniwa>
hayato: and shadow-dom is for v1?

[20:26:30.0000] <rniwa>
hayato: or are they mixed together?

[20:26:45.0000] <rniwa>
hayato: at some point, we should get gather and upstream these tests to W3C

[20:26:56.0000] <rniwa>
hayato: and make sure our behaviors are the same

[20:26:57.0000] <hayato>
Yeah, we separated it this week.

[20:27:02.0000] <rniwa>
hayato: nice!

[20:27:30.0000] <rniwa>
hayato: if we're going to have another in-person meeting, we can probably allocate a day before/after the meeting to do just that (upstream tests)

[20:27:40.0000] <rniwa>
because I suspect we'll have quite a bit of overlap between our tests

[20:27:48.0000] <rniwa>
(which is good though because we don't want one person writing all the tests)

[20:29:20.0000] <rniwa>
hayato: here's another weird case

[20:29:35.0000] <rniwa>
hayato: if you fired a scoped event inside a node that gets assigned to a slot

[20:29:52.0000] <rniwa>
hayato: then that event will propagate into the slot

[20:29:59.0000] <rniwa>
hayato: but never gets out of its shadow root

[20:30:01.0000] <rniwa>
that seems odd

[20:30:28.0000] <hayato>
It gets out of its shadow root.

[20:30:59.0000] <rniwa>
oh because of the check that Node is the root node of Target

[20:31:01.0000] <rniwa>
got it

[20:31:12.0000] <hayato>
Yeah, that's my intention.

[20:32:11.0000] <rniwa>
hayato: but that doesn't quite work

[20:32:21.0000] <rniwa>
hayato: if the target is in yet another shadow tree

[20:32:53.0000] <rniwa>
ugh... that's okay because we'd stop at the first shadow root

[22:06:58.0000] <annevk>
rniwa: non-node would mostly return just the target I think

[22:07:22.0000] <annevk>
rniwa: in IDB you might get multiple nodes

[22:07:46.0000] <annevk>
rniwa: hit regions also seem like they would be an exception

[22:13:34.0000] <rniwa>
annevk: can we have both non-Node and Node in a single event path?

[22:14:18.0000] <annevk>
rniwa: well, Window will be at the top for most paths

[22:14:41.0000] <rniwa>
annevk: is it supposed to be included in the path?

[22:14:52.0000] <annevk>
rniwa: for hit regions you might have a hit region object before the canvas element

[22:14:57.0000] <annevk>
rniwa: yes

[22:15:03.0000] <rniwa>
annevk: okay

[22:15:16.0000] <rniwa>
annevk: it appears after the document?

[22:15:25.0000] <rniwa>
annevk: or at the very beginning

[22:15:40.0000] <annevk>
rniwa: yeah, see document's get the parent

[22:15:44.0000] <rniwa>
annevk: cool

[22:16:07.0000] <rniwa>
annevk: so i guess when we're firing an event on non-Node object

[22:16:22.0000] <annevk>
rniwa: hit region would be at the start I think, but I have not sorted that yet

[22:16:35.0000] <rniwa>
annevk: oh no :( hit region case is convoluted

[22:16:44.0000] <rniwa>
annevk: in that one, the canvas can be inside a shadow DOM

[22:16:56.0000] <annevk>
Yes

[22:17:05.0000] <rniwa>
annevk: but we probably don't know about it :(

[22:17:10.0000] <rniwa>
because the target is not a node

[22:17:23.0000] <annevk>
But the way you calculate event paths you would

[22:17:42.0000] <rniwa>
annevk: how?

[22:17:43.0000] <annevk>
The target would be EventTarget though

[22:17:51.0000] <rniwa>
annevk: I'm talking about deepPath() here

[22:18:23.0000] <annevk>
Sure, but deepPath just returns the result of the path calculation, filtered

[22:19:10.0000] <rniwa>
annevk: by the current target

[22:19:24.0000] <rniwa>
annevk: but if the current target is not a node, how am I supposed to figure out which node is unclosed?

[22:19:56.0000] <annevk>
The path is calculated at the start of dispatch

[22:20:46.0000] <annevk>
So you should have all the info you need, I think, anyway, gotta go for a bit

[22:21:44.0000] <rniwa>
annevk: I think the problem here is that the we need to filter nodes at each current target separately

[22:22:04.0000] <rniwa>
annevk: I suppose we could find walk up the event path 'til the first target which is a node, and use that to filter the results

[22:22:13.0000] <annevk>
Yeah

[22:22:16.0000] <rniwa>
but some algorithm like that needs to be defined

[22:22:23.0000] <annevk>
Agreed

[22:22:49.0000] <annevk>
It's a shame the event stuff does not build more on DOM directly

[22:23:03.0000] <rniwa>
/me comments on the bug

[00:58:52.0000] <tobie>
I have errors I need to dispatch as error events. Where can I read more about how I'm supposed to do that?

[01:00:07.0000] <tobie>
Oh, in the HTML spec not the DOM spec.

[01:00:10.0000] <tobie>
Duh

[01:01:22.0000] <zcorpan>
it.... looks like github now has a mechanism for voting that is not adding a comment!

[01:09:06.0000] <tobie>
zcorpan: \o/

[01:12:32.0000] <pard>
hello

[01:14:07.0000] <pard>
i've got to ask something about auto margins and their behaviour on inline elements, as it looks rathe incosistent to me

[01:14:49.0000] <pard>
not sure if anyone is on the channel though

[01:14:50.0000] <pard>
:\

[01:18:08.0000] <pard>
my question is , why margin-right: auto is effectively 0 on inline elements?

[01:20:51.0000] <pard>
inline elements can have a deternmined width , which is what made me initially think UA's treat them (almost) like a div with a (max/min)-width

[01:21:02.0000] <pard>
turns out it was not the case :\

[01:22:39.0000] <pard>
the spec states the setting the side margins will be effective on block elements only

[01:23:30.0000] <pard>
*on block elements meeting certain criteria

[01:23:48.0000] <pard>
any ideas?

[01:28:26.0000] <pard>
/me used to think all the www consortium are on this channel

[01:30:33.0000] <tobie>
Trying to subclass Event (so doing `Event.call(this, type, options);` in my FooEvent constructor). Chrome throws a TypeError (Failed to construct 'Event': Please use the 'new' operator, this DOM object constructor cannot be called as a function.)

[01:30:46.0000] <tobie>
Is this by design or an implementation issue?

[01:31:11.0000] <tobie>
In either case is there a known workaround or best practice?

[01:39:48.0000] <Ms2ger>
tobie, subclassing dom objects is not supported

[01:39:57.0000] <Ms2ger>
Maybe in a few years

[01:57:26.0000] <tobie>
Ms2ger: what's the workaround for polyfilling event subclasses, then?

[01:58:57.0000] <tobie>
Ms2ger: this: https://github.com/w3c/sensors/blob/a1a777/polyfills/geolocation.js#L40-L45

[01:58:58.0000] <tobie>
?

[02:04:49.0000] <annevk>
/me wonders if anyone has actually reviewed web manifests... I looked at it briefly yesterday to see how it deals with icons and it talks about a [[HasOwnPropery]] internal method...

[02:05:44.0000] <annevk>
tobie: not sure there's a workaround really

[02:05:54.0000] <annevk>
tobie: you could use CustomEvent and stuff it all in .data

[02:06:38.0000] <annevk>
tobie: properly subclassing platform objects seems hard anyway given platform object's need for internal slots

[02:06:49.0000] <tobie>
annevk: sure, but then it's not a 1:1 match of what the spec is specifying (which has a reading property instead of a data prop)

[02:06:53.0000] <annevk>
I'm not sure if anyone really thought that all the way through

[02:07:03.0000] <tobie>
annevk: that's a good point, actually

[02:21:52.0000] <annevk>
MikeSmith: I think due to the component rename you did in WebAppsWG some Bugzilla links are now broken, e.g., new bug / open bugs on WebIDL

[04:11:20.0000] <smaug____>
Seriously, shipping Intersection Observer o_O

[04:12:40.0000] <smaug____>
I guess time to review the spec before blink ships anything :/

[05:17:39.0000] <annevk>
Domenic: how much nitpicking do you want on Custom Elements at this point?

[05:25:25.0000] <tobie>
On the sensor work, I have a start method that awakens the sensor and starts polling it. It returns a promise.

[05:27:18.0000] <tobie>
Should I explicitly prevent events from being emitted if the stop method is called before the start method's promise is resolved?

[05:28:22.0000] <annevk>
tobie: seems cleaner, yes

[05:28:32.0000] <annevk>
tobie: stop() should probably cause the promise to be rejected, too

[05:29:00.0000] <tobie>
oh. I hadn't thought of that. makes sense, yes.

[05:29:50.0000] <tobie>
annevk: seems the best way to handle that is to have a private state for the sensor, no?

[05:30:16.0000] <tobie>
idle / starting / polling or something

[05:31:45.0000] <annevk>
tobie: yeah, you might even want to expose that through sensor.state

[05:32:05.0000] <tobie>
annevk: ty

[05:36:33.0000] <annevk>
"It turns out there's not actually a spec for the XML parser. Awesome! (Not actually awesome.)"

[05:46:42.0000] <jgraham>
Not actually surprising?

[05:50:30.0000] <gsnedders>
I thought we all knew that?

[05:51:46.0000] <gsnedders>
(But I have no context for where that quote was from)

[05:51:47.0000] <annevk>
Yeah, I just liked the sentence

[05:51:58.0000] <annevk>
https://w3c.github.io/webcomponents/spec/custom/

[05:55:50.0000] <Domenic>
annevk: consolidated nitpicking, or better yet PRs, would be welcome. And anything that would be better to catch now instead of during a merge.

[05:56:14.0000] <gsnedders>
So what we want to do is define infoset -> DOM and DOM -> infoset, right? So we have the whole platform well-defined.

[05:56:17.0000] <gsnedders>
/me hides

[05:58:21.0000] <annevk>
gsnedders: doesn't actually work given <script> and such executing synchronously

[06:00:41.0000] <annevk>
yoav: did you look into the perf benefits of disabling document.write(), not having sync scripts/stylesheets/scroll events, etc.? It seems letting a site disable those could allow a browser to make a number of optimizations that are hard or impossible now

[06:05:18.0000] <gsnedders>
annevk: I thought scripts didn't execute synchronously with XML, am I just forgetting, bah…

[06:05:38.0000] <gsnedders>
annevk: still, we need to address how XPath and XSLT interact with the DOM world.

[06:06:35.0000] <annevk>
gsnedders: you are, or maybe you didn't test

[06:27:56.0000] <annevk>
/me finds https://www.w3.org/blog/news/archives/5313

[06:28:22.0000] <annevk>
/me loads https://lists.w3.org/Archives/Public/public-webapps/latest

[06:28:31.0000] <annevk>
I guess we stopped asking the WG about publications?

[06:30:47.0000] <annevk>
/me finds https://www.w3.org/blog/2016/03/html-whats-next/

[06:30:55.0000] <annevk>
Seems to get particularly rambly in the end

[06:31:35.0000] <annevk>
"An important part of W3C work is getting commitments to provide Royalty-Free patent licenses from organisations, and for some large companies with many patents that approval takes time. At the same time, Art Barstow who was for many years co-chair of Web Apps, and an initial co-chair of this group, has had to step down due to other responsibilities." This

[06:31:35.0000] <annevk>
almost makes it seem like Art stepped down due to patent issues, which couldn't be further from the truth...

[06:37:18.0000] <gsnedders>
Why did Art step down?

[06:37:27.0000] <gsnedders>
/me has entirely missed his departure

[06:39:34.0000] <yoav>
annevk: we are looking into exactly that. I'd love to have you involved

[06:40:00.0000] <annevk>
His current employer does not fund this kind of activity, I think, best to just email him directly gsnedders

[06:40:31.0000] <gsnedders>
annevk: ah

[06:41:23.0000] <annevk>
yoav: if there's one thing I'd say about how CSP went down is that CSP didn't look carefully enough at the detailed picture of how features fit together

[06:41:55.0000] <annevk>
yoav: I'd try to avoid that by really exploring the architecture of the things you want to effect

[06:42:25.0000] <annevk>
(This advice really goes for any new standard, I suppose)

[06:44:23.0000] <yoav>
Yeah, I guess the practical takeaway would be to let the folks that got burned the last time review things at an early stage

[06:47:43.0000] <annevk>
yoav: also, if you can't "monkey patch" your change without doing some contorted, that's indicative of a problem

[06:48:07.0000] <annevk>
doing something*

[06:48:49.0000] <yoav>
I'll keep that in mind :)

[06:49:08.0000] <annevk>
yoav: and please do define everything as a monkey patch, makes it much easier to review the feasibility of something and will save you work down the line

[06:49:55.0000] <nox>
Wtf is HTML 5.1?

[06:50:32.0000] <Ms2ger>
Yet another fork

[06:50:42.0000] <nox>
How many of them are there?

[06:50:52.0000] <jgraham>
nox: s/?// and your setence makes sense still

[06:51:09.0000] <nox>
Hah.

[06:51:55.0000] <nox>
Also,

[06:52:07.0000] <nox>
how come an article named "HTML: WHAT’S NEXT?" not mention WHATWG at all?

[06:52:45.0000] <nox>
Are they always that tsun-tsun?

[06:54:02.0000] <gsnedders>
https://lists.w3.org/Archives/Member/chairs/2016JanMar/0106.html has dates/location for TPAC 2017 (Member-Only, sadly)

[06:54:32.0000] <annevk>
/me looks up tsun-tsun

[06:54:41.0000] <annevk>
Seems about right

[06:56:00.0000] <annevk>
W3C is sometimes very reminiscent of a British TV show I used to watch with my mom, Keeping Up Appearances

[06:56:02.0000] <nox>
annevk: So their fork doesn't even use the same tools nor sources?

[06:56:08.0000] <Ms2ger>
Indeed

[06:56:21.0000] <Ms2ger>
(Mind the pedestrians?)

[06:59:23.0000] <Domenic>
> How many of them are there?

[06:59:31.0000] <Domenic>
nox: I'm glad you asked!! https://wiki.whatwg.org/wiki/Fork_tracking

[07:00:23.0000] <annevk>
And that doesn't even contain an exhaustive list of the twenty-odd canvas forks Hixie_ collected at one point

[07:04:59.0000] <gsnedders>
twenty-odd?!

[07:05:27.0000] <nox>
Is that a French number I don't know about? :P

[07:13:23.0000] <annevk>
gsnedders: http://damowmow.com/temp/canvas-specs

[07:13:27.0000] <Ms2ger>
annevk, at least http://w3c.github.io/webmessaging/ is nice now

[07:20:18.0000] <gsnedders>
annevk: oh, ok, mostly just stuff in TR space

[07:21:03.0000] <annevk>
Mostly, but also nine elsewhere

[07:24:12.0000] <hallvors>
annevk: is this the right fix? Sorry if I'm doing a crappy job here.. :-p https://github.com/w3c/clipboard-apis/issues/10#issuecomment-195394397

[07:25:35.0000] <annevk>
hallvors: for making it nullable that seems fine

[07:25:53.0000] <annevk>
hallvors: I think you do want to set a default though if you don't require the argument, per philipj_'s comment

[07:26:04.0000] <annevk>
hallvors: can't help you with ReSpec though

[07:26:29.0000] <hallvors>
did I come across a ReSpec bug, then?

[07:27:04.0000] <hallvors>
/me needs to understand WebIDL

[07:27:14.0000] <hallvors>
/me lacks time

[07:29:17.0000] <annevk>
hallvors: actually, where do you define the init dictionary?

[07:29:22.0000] <annevk>
hallvors: that is where you want to define the default

[07:29:47.0000] <annevk>
hallvors: in ClipboardEventInit, I think you're correct that it's wrong here

[07:31:12.0000] <hallvors>
I need to fix the example script just above too

[07:31:23.0000] <hallvors>
perhaps tests are wrong..

[07:31:36.0000] <hallvors>
this wasn't a quick fix after all :-p

[07:33:41.0000] <hallvors>
Poorly worded issue that will make sure I follow up later:

[07:33:42.0000] <hallvors>
https://github.com/w3c/clipboard-apis/issues/10#issuecomment-195394397

[07:34:08.0000] <hallvors>
wrong paste. https://github.com/w3c/clipboard-apis/issues/27

[08:01:59.0000] <MikeSmith>
annevk: I can revert the names on any of the bugzilla components that need it

[08:02:48.0000] <annevk>
MikeSmith: I haven't done a thorough analysis, there's no way to just close the component to new bugs, but leave old links working?

[08:03:12.0000] <annevk>
MikeSmith: maybe it doesn't matter much if only I notice it

[08:39:24.0000] <MikeSmith>
annevk: they have/had some kind of convention of prepending HISTORICAL- to the components to indicate that they were closed. So I tried to follow that, mostly just so that it looked like somebody who was authorized to do it knew that convention had closed them

[08:40:31.0000] <MikeSmith>
but anyway I reverted the WebIDL component at least

[08:41:00.0000] <MikeSmith>
and I’ll go back and do the same for the others I changed recently (once I remember which those are)

[09:32:24.0000] <annevk>
Domenic: have you thought about merging environment settings objects into Realms btw?

[09:33:01.0000] <annevk>
Domenic: as in, by just creating Host-defined record fields on Realms

[09:33:49.0000] <Domenic>
annevk: I thought there were cases where they weren't 1:1?

[09:34:07.0000] <annevk>
Domenic: bz says he's pretty sure they're 1:1

[09:34:14.0000] <annevk>
/me is not sure

[09:34:41.0000] <Domenic>
I think ES also prefers you stuff everything into a single HostDefined slot on their objects. At which point the thing you stuff in there basically is the settings object.

[09:35:02.0000] <annevk>
Domenic: right, might still be worth doing

[09:35:18.0000] <annevk>
Domenic: if only to make everything explicit

[09:35:35.0000] <nox>
Does any UA pass /css21_dev/html4/quotes-036.htm?

[09:35:53.0000] <annevk>
Domenic: oh, I raised https://github.com/whatwg/html/issues/167 for this at one point

[09:37:09.0000] <Domenic>
I guess the distinction between the three concepts has kind of grown on me

[09:37:35.0000] <Domenic>
Global object = thing JS uses, with internal slots to support its public APIs

[09:37:48.0000] <Domenic>
Realm = more general JS engine concept

[09:38:02.0000] <Domenic>
Settings object = more general web browser concept

[09:38:34.0000] <Domenic>
Making the link explicit and maybe adding an explanation like the above to the spec seems good.

[09:40:48.0000] <annevk>
It's a little uncomfortable that in impls they're typically just one thing, but I guess that'll change with new Realm()

[09:43:54.0000] <Domenic>
Hmm I don't think that's true

[09:43:59.0000] <Domenic>
V8 separates Realm and global object at least

[09:44:16.0000] <Domenic>
Realm <-> v8::Context, which has a v8::Object for the global object, roughly

[09:45:16.0000] <Domenic>
And then I believe there's some supertype in blink that contains a v8::Context, creates the appropriate v8::Object for window, and contains all the different behavior. That supertype is where the settings object stuff goes I imagine

[09:46:45.0000] <annevk>
So a settings object holds a Realm?

[09:47:00.0000] <annevk>
Oh well, doesn't matter

[09:47:13.0000] <annevk>
I think in Gecko they are the same

[09:47:42.0000] <Domenic>
I think settings object doesn't correspond to anything very exactly

[09:47:44.0000] <annevk>
But we should design with what we think the setup will be

[09:47:45.0000] <Domenic>
(in Blink)

[09:48:30.0000] <Domenic>
I guess I'd like to put everything inside Realm and define things in terms of that. I'll comment on the bug.

[09:49:10.0000] <Domenic>
http://krijnhoetmer.nl/irc-logs/ doesn't have last two months?

[09:49:25.0000] <annevk>
Yeah, not sure what's up with krijn's server

[09:49:42.0000] <annevk>
krijn: awake?

[09:50:19.0000] <annevk>
I solved it for myself with IRCCloud, so I kinda stopped caring about it, not the best, I realize

[09:53:24.0000] <krijn>
People stopped caring, like you said

[09:53:39.0000] <krijn>
Myself included

[09:53:49.0000] <annevk>
krijn: heh, it had a good run

[09:54:15.0000] <krijn>
Setup is too shitty, so it will break eventually

[09:54:22.0000] <annevk>
krijn: it's still useful at times I think to be able to point somewhere, but if it's too much trouble, understood

[09:54:51.0000] <krijn>
It'll stay up forever-ish, just not adding new stuff anymore

[09:54:58.0000] <krijn>
Hard disk is full as well :]

[09:55:26.0000] <krijn>
1.2gb of text

[09:58:12.0000] <krijn>
(Also, I measured the amount of effort to put in on the number of donations, which I shouldn't have done ;)

[10:00:39.0000] <astearns>
krijn: just donated - not to bring it back, necessarily. Just in appreciation for the last few years

[10:15:40.0000] <TabAtkins>
krijn: Patreon for donations, yo.

[10:20:39.0000] <krijn>
astearns: thanks!

[10:22:03.0000] <krijn>
TabAtkins: that site that needs 1.3mb of JS to load? Grr!

[10:22:30.0000] <TabAtkins>
krijn: Hey, they have their sins, but they're *ridic* good for getting small regular donations from people.

[10:22:47.0000] <TabAtkins>
I'm currently in for ~$60/month to a bunch of folks.

[10:23:38.0000] <krijn>
(It's not really about the money, though, caring is an issue atm. Sorry HTML5 cabal!)

[10:29:45.0000] <jyasskin>
I'm working on adding an "interface" to https://w3c.github.io/permissions/#permission-registry, something like the environment settings object interface, except I expect it to be implemented more widely. Are there examples of similar things elsewhere? I'm especially looking for good ways to describe the argument and return types of the algorithms folks will

[10:29:46.0000] <jyasskin>
need to override.

[10:30:26.0000] <Domenic>
jyasskin: "interface" in this case is not "IDL interface"?

[10:30:42.0000] <jyasskin>
Right, it's a set of algorithms that vary by permission.

[10:31:17.0000] <Domenic>
Hmm hmm. I can think of a few examples, but IIRC they aren't terribly specific about argument and return types... let me see.

[10:31:24.0000] <jyasskin>
For example, https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object is an interface that's implemented at https://html.spec.whatwg.org/multipage/browsers.html#script-settings-for-browsing-contexts.

[10:31:49.0000] <jyasskin>
I'm happy to make up a convention if none exists, but it's always nicer to be able to copy.

[10:31:56.0000] <Domenic>
jyasskin: https://html.spec.whatwg.org/#fetching-scripts-set-up-request might be close to what you're thinking

[10:34:00.0000] <Domenic>
oooh i think i have one

[10:34:13.0000] <Domenic>
jyasskin: https://dom.spec.whatwg.org/#get-the-parent

[10:35:03.0000] <jyasskin>
Yeah, that's a good example.

[11:45:36.0000] <jgraham>
annevk: You can point people to glob's logs I guess

[12:59:47.0000] <jyasskin>
Domenic: See https://rawgit.com/jyasskin/permissions/allow-choosers/index.html#permission-registry for how it turned out. Comments are welcome on https://github.com/w3c/permissions/pull/66.

[13:19:39.0000] <Domenic>
jyasskin: looks like a pretty sweet setup, very nice

[13:19:43.0000] <jyasskin>
Thanks!


2016-03-12
[05:29:07.0000] <annevk>
Maybe we should get botbot.me as logger, HTTPS, looks good


2016-03-13
[22:40:31.0000] <annevk>
MikeSmith: it seems for DOM the Bugzilla link broke as well

[22:41:26.0000] <annevk>
MikeSmith: maybe time has come to more aggressively move things to GitHub, just seems a bit spammy on both sides

[03:18:58.0000] <tobie>
I have a `start` method that transitions state (it starts the sensor polling, and goes from state=idle to state=active) and returns a promise. Should it return the same promise if it's called a second time?  Or should it return a new promise each time it's called?

[03:19:34.0000] <tobie>
i.e. should: sensor.start() === sensor.start() ?

[03:22:27.0000] <tobie>
^ Domenic: looked at your TAG findings on the topic and while this seems clear for  props (e.g. dom.ready.then...) it wasn't obvious for methods.

[06:22:02.0000] <annevk>
tobie: why not just only allow it to be called in the idle state?

[06:39:30.0000] <tobie>
annevk: so reject the promise otherwise? Seems less user friendly though.

[06:45:15.0000] <annevk>
tobie: nobody really complains about that aspect of XHR

[06:45:57.0000] <annevk>
tobie: but dunno, seems somewhat better than storing the promise

[06:48:00.0000] <tobie>
Definitely easier to spec. :)


2016-03-14
[01:32:24.0000] <annevk>
FWIW, I informed the IETF of our forking of WebSocket: https://mailarchive.ietf.org/arch/msg/hybi/2OIyLSs5JjDfiFB_I_HGoSinsqc

[02:58:25.0000] <zcorpan>
reflecting as URL seems to have more issues. returns resolved URL when the attribute is absent... <a>.href seems to be better defined. looks like there might be an issue with blob: URLs also. annevk thoughts? should reflect as URL reuse <a>.href machinery?

[02:59:18.0000] <annevk>
zcorpan: I think technically reflecting a URL requires an internal slot for the URL

[02:59:37.0000] <annevk>
zcorpan: this is a problem for most of the reflecting stuff though, that they require an internal slot

[03:00:05.0000] <zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3994 - difference between gecko and chromium

[03:00:10.0000] <annevk>
zcorpan: I filed a bug on IDL to automatically get internal slots for attributes, unless specified otherwise, but you know how well IDL is maintained

[03:03:04.0000] <zcorpan>
annevk: ok, i think i'll fix some low-hanging fruit today with resolve as url and revisit to do it "properly" some other day

[03:06:55.0000] <annevk>
Yeah, I think we should fix IDL for the proper fix

[03:07:40.0000] <annevk>
It would be nice to standardize [Reflect=URL] or some such too

[03:07:46.0000] <zcorpan>
yeah

[03:08:37.0000] <zcorpan>
oh the spec does handle absent attribute actually

[03:13:10.0000] <zcorpan>
is there any attribute that takes a URL and has a default value? I can't find any

[03:20:37.0000] <annevk>
Seems unlikely

[03:20:50.0000] <annevk>
Don't know for sure though

[03:48:57.0000] <annevk>
jgraham: can the web-platform-tests server be used to transmit a response early?

[03:49:47.0000] <Ms2ger>
What does that mean?

[03:50:06.0000] <annevk>
Ms2ger: transmit a response before the entire request is in

[03:50:11.0000] <Ms2ger>
Hmm

[03:50:22.0000] <annevk>
See https://github.com/whatwg/fetch/issues/229 for context

[03:50:28.0000] <Ms2ger>
I don't know, but I wouldn't be surprised if it couldn't

[03:51:40.0000] <jgraham>
annevk: I doubt it

[04:41:17.0000] <glazou>
zcorpan: ping

[04:41:23.0000] <zcorpan>
glazou: pong

[04:41:26.0000] <glazou>
hi

[04:41:38.0000] <glazou>
I have a question about DOM spec

[04:42:09.0000] <glazou>
https://dom.spec.whatwg.org/#dom-range-clonecontents is supposed to clone a Range but returns a DocumentFragment :-)

[04:42:25.0000] <glazou>
because of https://dom.spec.whatwg.org/#concept-range-clone that itself returns a DocumentFragment

[04:44:36.0000] <Ms2ger>
  [NewObject] DocumentFragment cloneContents();

[04:44:45.0000] <Ms2ger>
Why would it return a Range?

[04:44:49.0000] <zcorpan>
Ms2ger was faster than me

[04:44:50.0000] <zcorpan>
:-)

[04:45:02.0000] <glazou>
I really need to stop coffee and go back to beer

[04:45:02.0000] <zcorpan>
glazou: confused with [NewObject] Range cloneRange(); ?

[04:45:11.0000] <Ms2ger>
Now zcorpan beat me :)

[04:45:25.0000] <glazou>
zcorpan: I need vacation, that's all; nm and sorry for annoyance

[04:46:16.0000] <Ms2ger>
Np

[04:46:45.0000] <glazou>
yeah probably a confusion because of "clone" ; a "clone" operation that does not return the same object type... hmmm...

[04:47:39.0000] <zcorpan>
it is confusing, agreed

[04:47:55.0000] <zcorpan>
the concept should maybe be called "clone the contents"

[04:48:46.0000] <zcorpan>
/me can PR

[04:48:58.0000] <glazou>
yes that would help

[04:50:29.0000] <benjamingr__>
caitp, littledan__  : hey, I'd love your opinion on https://github.com/nodejs/node/issues/5691#issuecomment-196275629

[06:04:56.0000] <caitp>
benjamingr__: as far as I can tell from api.cc, those api methods just call into the self hosted promise implementation anyways

[06:05:04.0000] <caitp>
so I'm not sure why there would be any difference between them, at least on ToT

[06:10:50.0000] <caitp>
so, Promise::Resolver::Resolve() will enqueue a microtask, so long as the promise wasn't already resolved

[06:12:10.0000] <caitp>
oh I see

[06:13:34.0000] <annevk>
Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25529 might be of interest (about cloning)

[06:27:50.0000] <annevk>
smaug____: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19962?

[06:34:59.0000] <smaug____>
annevk: yeah, I guess we could add those, given that Gecko has now innerText too and insertAdjacentHTML()

[06:35:06.0000] <smaug____>
hsivonen might have some comment

[06:35:10.0000] <smaug____>
(is he back?)

[06:50:13.0000] <smaug____>
we need a bot to file browser engine bugs

[06:51:29.0000] <annevk>
smaug____: I didn't know he was gone

[06:53:19.0000] <smaug____>
Looks like still away this week

[07:45:25.0000] <annevk>
Ms2ger: FYI: https://github.com/w3c/DOM-Parsing/issues/4

[07:45:42.0000] <annevk>
smaug____: harder to spec than I thought

[07:46:17.0000] <annevk>
philipj_: I found a bug in Blink, it says insertAdjacentElement returns "Element" in your IDL, but it's actually "Element?" per impl (and now spec)

[07:46:42.0000] <Ms2ger>
I didn't fix issues with that spec when I edited it, not going to start now :)

[07:47:03.0000] <zcorpan>
hmmm... http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3998 the spec says absent.href should return http://example.org/ afaict but webkit/chromium/gecko don't do that

[07:47:22.0000] <zcorpan>
can someone check Edge?

[07:47:41.0000] <annevk>
Ms2ger: you didn't write that part? I thought you did

[07:47:46.0000] <annevk>
Ms2ger: anyway, never mind then

[07:47:52.0000] <Ms2ger>
I probably did write it

[07:48:03.0000] <annevk>
I should probably fold that whole spec into DOM at some point

[07:48:10.0000] <Ms2ger>
No time to maintain, though

[07:48:32.0000] <Ms2ger>
Of course it's in licensing hell now

[07:49:11.0000] <annevk>
Ms2ger: hmm yeah, I guess the additions are

[07:49:17.0000] <annevk>
ugh

[07:53:47.0000] <annevk>
/me was about to add CDATASection back but then figured out he isn't 30 yet

[07:56:30.0000] <tantek>
/me lol annevk 

[07:59:13.0000] <zcorpan>
philipj_: still not excited to remove CDATASection? still have a few months :-) https://www.w3.org/Bugs/Public/show_bug.cgi?id=27386

[08:00:59.0000] <zcorpan>
https://www.chromestatus.com/metrics/feature/timeline/popularity/113 0.0048%

[08:51:59.0000] <annevk>
So low and yet too high

[09:04:00.0000] <KiChjang>
i'm currently writing a white paper on the evolution of HTTP, and am wondering what i can include in there

[09:06:35.0000] <annevk>
KiChjang: that's a very generic question, anything specific?

[09:08:23.0000] <KiChjang>
annevk: i'm currently considering how every subsequent versions is trying to fix or improve upon previous versions

[09:08:59.0000] <KiChjang>
like how HTTP/0.9 is a really simple protocol designed to transfer HTML documents as-is without any metadata attached to responses and requests

[09:09:07.0000] <annevk>
KiChjang: I guess you could say that HTTP/1.0 obviated the need for <plaintext>

[09:09:46.0000] <annevk>
but we still have it because HTTP/0.9 was a real thing

[09:09:49.0000] <KiChjang>
annevk: obviated?

[09:09:57.0000] <KiChjang>
as in, it assumes plaintext is used?

[09:10:00.0000] <annevk>
KiChjang: removed the need for

[09:10:19.0000] <annevk>
KiChjang: HTTP/0.9 did content sniffing, afaik

[09:30:31.0000] <annevk>
smaug____: perhaps you know what we should do with https://www.w3.org/Bugs/Public/show_bug.cgi?id=28097?

[09:31:22.0000] <annevk>
Domenic: I thought your custom element work resulted in an abstract operation for creating all elements

[09:31:47.0000] <annevk>
Domenic: which could then have some kind of "element created steps" associated with it, if specifications needed a hook

[09:43:08.0000] <Domenic>
annevk: I guess it could. What does that help with though?

[09:43:37.0000] <Domenic>
annevk: looking through HTML's existing "when the element is created" it's basically just specifying what the UA-callable-only constructor does

[09:45:37.0000] <annevk>
Domenic: I think the main problem Hixie_ had was with attributes, where browsers assume that elements created by the parser are created with attributes, so the question I guess is what happens for cloning

[09:46:02.0000] <Domenic>
annevk: https://w3c.github.io/webcomponents/spec/custom/#clone-modifications-to-dom should hopefully cover it?

[09:46:09.0000] <annevk>
Domenic: I don't immediately know what the observables would be though

[09:46:48.0000] <smaug____>
annevk: looking

[09:47:14.0000] <annevk>
Domenic: yeah, shouldn't typeExtension be an optional argument as well?

[09:47:42.0000] <Domenic>
annevk: my intention was you always supply null. I guess I messed that up in the cloning section.

[09:53:10.0000] <annevk>
philipj_: FWIW, I might actually add CDATASection back before August

[09:53:19.0000] <Domenic>
:(

[09:53:25.0000] <Domenic>
I wish someone would make the parser change

[09:53:33.0000] <caitp>
do you think it would make sense for browserland SVG to be specified in a living standard? all vendors seem to differ in at least a few ways from the snapshot editions

[09:53:36.0000] <Domenic>
It seems plausible that using Text nodes would work

[09:54:00.0000] <annevk>
philipj_: ooh, maybe not, I was thinking it was required for Shadow DOM, but it's not, whatever Shadow DOM adds to Text ends up automatically on CDATASection

[09:54:19.0000] <Domenic>
caitp: I think it would make sense for everything to be specified in a living standard. But, it's up to the editors who have the bandwidth to work on those technologies, and I don't think the SVGWG is that excited about doing so.

[09:54:24.0000] <annevk>
Domenic: I think philipj_ tried and it broke tests at least, e.g., some serialization expectations

[09:54:38.0000] <Domenic>
caitp: in the meantime we have https://html.spec.whatwg.org/#svg-0

[09:54:48.0000] <Domenic>
annevk: yeah, i meant try for real

[09:54:56.0000] <Ms2ger>
A long time ago (when vendor prefixes were still in fashion), I implemented mozSerializeAsCDATA

[09:55:07.0000] <Ms2ger>
(Never landed)

[09:55:30.0000] <annevk>
I have pondered about defining SVG, but it's quite a bit of work

[09:55:48.0000] <annevk>
As is it's quite a mess though, with nothing really well defined 😟

[09:56:04.0000] <caitp>
I just meant some basic ways, was trying to figure out why we add @@iterator to SVGxxList interfaces, blink and geck give it a "length" attribute, but apparently webkit doesn't

[09:56:11.0000] <caitp>
gecko*

[09:56:20.0000] <caitp>
there are probably other things

[09:56:38.0000] <annevk>
caitp: I was thinking basics too, e.g., how <svg:script> works

[09:56:44.0000] <Domenic>
Ooh caitp you're setting yourself up for a PhiStucK email with that "no feature dashboard" entry. Just wait for it...

[09:57:23.0000] <caitp>
there are enough chromestatus pieces for real features that people consciously care about :x

[09:57:43.0000] <annevk>
caitp: at some point the complex stuff is hopefully all abstracted through CSS, and then the remaining complex stuff can be abstracted through HTML

[10:09:06.0000] <jsbell>
Domenic: only if joe doesn't beat phistuck to it...

[10:10:01.0000] <annevk>
Domenic: hayato: I think tomorrow I'm going to try to add attachShadow(), ShadowRoot and the ShadowRootOrDocument mixin to DOM, and update the various algorithms that need to account for them

[10:11:15.0000] <annevk>
Domenic: hayato: and then as exercise I'll try to update Fullscreen, if that's feasible without the flat tree

[10:11:43.0000] <Domenic>
annevk: sounds ambitious, awesome!

[10:12:30.0000] <annevk>
Just the basic building blocks, but yeah, might end up being more than anticipated, we'll see

[10:13:13.0000] <annevk>
The alternative is probably working on outstanding Fullscreen/Storage issues

[10:50:46.0000] <annevk>
jsbell: https://github.com/whatwg/encoding/issues/18, do it?

[10:58:20.0000] <jsbell>
annevk: yep.

[11:07:44.0000] <annevk>
jsbell: so exciting to get rid of that

[11:08:08.0000] <annevk>
jsbell: makes the constructor argument are a bit useless, but okay

[11:08:17.0000] <annevk>
s/are//

[11:14:27.0000] <Domenic>
annevk: can't you just remove the constructor argument?

[11:15:45.0000] <annevk>
Domenic: I guess we could, though it's probably impossible to introduce a different argument at a later stage

[11:16:00.0000] <annevk>
Domenic: but I can make sure that doesn't happen by leaving some kind of note in the source

[11:16:13.0000] <Domenic>
yeah that makes sense

[11:16:25.0000] <Domenic>
can also remove the encoding internal slot

[11:16:54.0000] <annevk>
Actually, should probably keep the first argument, so that it keeps throwing for invalid values

[11:18:23.0000] <annevk>
But yeah, can simplify a couple of things

[11:18:33.0000] <Domenic>
why though

[11:18:37.0000] <annevk>
Next big change after this will probably be streams integration

[11:18:39.0000] <Domenic>
don't throw just ignore it

[11:19:04.0000] <Domenic>
annevk: I don't think anything else on the platform validates an argument it does nothing with.

[11:19:28.0000] <annevk>
Domenic: I guess that's true, I'm mostly worried what happens if we want to add that argument back, but maybe that's not going to be a thing

[11:19:58.0000] <Domenic>
annevk: yeah I don't think it will be. It'll all be fine...

[11:25:40.0000] <KiChjang>
what's HTTPbis?

[11:26:27.0000] <gsnedders>
KiChjang: the set of RFCs that obsoleted RFC 2616

[11:26:32.0000] <gsnedders>
KiChjang: the revision to HTTP/1.1 specs

[11:27:06.0000] <KiChjang>
i thought RFC2616 was the latest HTTP/1.1 spec

[11:27:10.0000] <KiChjang>
so there are others

[11:27:52.0000] <gsnedders>
KiChjang: RFC 7230–7235

[11:28:04.0000] <KiChjang>
gsnedders, ah, so SPDY stuff?

[11:28:39.0000] <gsnedders>
KiChjang: no

[11:28:47.0000] <gsnedders>
KiChjang: this is a simple revision of the HTTP/1.1 spec

[11:29:08.0000] <gsnedders>
KiChjang: SPDY became HTTP/2.0 which is RFC 7540

[11:40:05.0000] <KiChjang>
is HTTP/2 stateful?

[11:40:13.0000] <KiChjang>
it looks like it is, since it has this concept of a stream

[11:53:56.0000] <smaug____>
annevk: finally looked at https://www.w3.org/Bugs/Public/show_bug.cgi?id=28097 but couldn't immediately understand what it even is about. Why any of this stuff has anything to do with host-inclusiveness ?

[11:55:03.0000] <smaug____>
oh, hmm, is this about the cycle?

[11:56:46.0000] <smaug____>
which isn't there...

[11:56:53.0000] <smaug____>
yeah, don't really understand the bug

[11:58:14.0000] <smaug____>
pre-insertion validity check shouldn't probably use "host-including inclusive ancestor "

[14:19:39.0000] <gsnedders>
KiChjang: what sort of statefulness do you mean?

[14:20:08.0000] <gsnedders>
KiChjang: there's no statefulness exposed at the request/response layer beyond what HTTP/1.1 has as the messaging semantics are unchanged

[14:48:26.0000] <Domenic>
TabAtkins: where did "Document Object Model" come from for https://storage.spec.whatwg.org/#normative ?

[14:48:43.0000] <Domenic>
TabAtkins: nevermind, I guess that hasn't been recompiled in a long time

[14:51:09.0000] <TabAtkins>
Domenic: Yeah, it used to be that SpecRef had the W3C version squatting on "DOM", and Shepherd named their ref (which points to the WHATWG copy) dom-ls, so you reffed that.  I've since fixed things - the Shepherd ref is now just "DOM", and Bikeshed has an explicit fixup for the squatted WHATWG specs, so biblio-reffing "DOM" will grab all the right data from

[14:51:09.0000] <TabAtkins>
SpecRef's WHATWG-DOM reference.

[14:51:41.0000] <Domenic>
TabAtkins: but it will still show [WHATWG-DOM] as the name, IIRC? Kind of sad.

[14:52:02.0000] <TabAtkins>
It's the result of me applying a lowest-cost fix, until SpecRef fixes itself properly.

[14:52:19.0000] <Domenic>
I have little confidence in SpecRef fixes sadly

[14:52:35.0000] <TabAtkins>
Eh, I believe he'll fix it eventually.

[14:53:02.0000] <TabAtkins>
In the meantime, it only shows as [WHATWG-DOM] in the biblio index; any explicit `[[DOM]]` tags in your source stay that way.

[14:54:31.0000] <Domenic>
Which honestly just seems like a bug? A link text [DOM] going to a [WHATWG-DOM] in the index?

[14:54:59.0000] <Domenic>
It's like, no, I clicked on [DOM], not [WHATWG-DOM]... now I need to scroll up to find where [DOM] is defined... argh it isn't there, where did it go?

[15:05:34.0000] <TabAtkins>
Like I said, lowest-effort fix.  Removing this when SpecRef is fixed will be a 2-line deletion commit.

[16:14:36.0000] <tobie>
Domenic: Fwiw, I'm happy to accept a PR in Specref that fixes the problem. I just don't have time to look into it myself right now.

[16:17:05.0000] <tobie>
I agree that this is a problem and want to fix it.

[16:18:07.0000] <tobie>
But I also want to make sure it doesn't get overwritten with the next update and that we don't loose references to previous specs in the process.

[16:45:50.0000] <rniwa>
Domenic: is anyone working on new custom elements API in Blink?

[16:49:08.0000] <Domenic>
rniwa: kochi is

[16:49:27.0000] <rniwa>
Domenic: cool. is there an issue that I can follow?

[16:51:15.0000] <Domenic>
rniwa: I will ask him

[16:51:24.0000] <rniwa>
Domenic: thanks

[16:51:40.0000] <rniwa>
Domenic: between late March and early April, which one do you prefer for a telecon?

[16:52:05.0000] <Domenic>
rniwa: probably early April; TC39 is the last week of March.

[16:52:11.0000] <rniwa>
Domenic: okay

[16:55:13.0000] <rniwa>
Domenic: alright, I just asked for one on public-webapps

[16:55:20.0000] <rniwa>
Domenic: btw, we really appreciate your work for the spec :)

[16:56:10.0000] <rniwa>
Domenic: so are you guys going to be fine with having an explicit method for upgrading custom elements?

[16:56:36.0000] <rniwa>
Domenic: and not upgrading any elements by default when there is no definition at the time of element construction?

[16:56:49.0000] <rniwa>
Domenic: or do you still want the HTML parser to set the flag for auto-upgrades?

[16:57:01.0000] <Domenic>
rniwa: yeah we're having a meeting tomorrow to make sure everyone is on the same page but it looks like maybe a move to in-document-only upgrades is on the table

[16:57:31.0000] <Domenic>
like you originally proposed


2016-03-15
[17:07:12.0000] <rniwa>
Domenic: okay

[17:07:19.0000] <rniwa>
Domenic: let me know how that goes

[01:30:17.0000] <annevk>
TabAtkins: is it bikeshed or specref that causes {{DOMString}} to link to http:// rather than https://?

[01:49:58.0000] <Ms2ger>
annevk, https://github.com/w3c/web-platform-tests/pull/2667 really is unspecified?

[01:52:33.0000] <annevk>
Ms2ger: there's a number of mistakes there

[01:53:14.0000] <annevk>
Ms2ger: status should be 200 for a data URL, statusText "OK"

[01:53:27.0000] <annevk>
Ms2ger: ooh wait, non-GET

[01:58:43.0000] <annevk>
Ms2ger: commented

[01:58:50.0000] <Ms2ger>
Thanks

[01:58:54.0000] <annevk>
Ms2ger: but yes, we need a data URL spec

[02:04:43.0000] <Ms2ger>
Added it to https://wiki.whatwg.org/wiki/Specs/todo

[02:06:28.0000] <annevk>
https://twitter.com/mrphs/status/708548201800982528 is neat

[02:06:44.0000] <annevk>
I wonder if that should be in Fetch

[02:32:40.0000] <tobie>
annevk: which spec are you having the DOMstring issue in?

[02:32:48.0000] <annevk>
tobie: DOM

[02:33:04.0000] <annevk>
tobie: https://dom.spec.whatwg.org/#dom-core-changes

[02:34:04.0000] <tobie>
annevk: seems to be a bikeshed issue: http://www.specref.org/?q=webidl

[02:40:04.0000] <tobie>
annevk: afaik, bikeshed doesn't use Specref for x-spec references.

[02:40:40.0000] <annevk>
tobie: yeah, it uses Shepherd, sorry

[02:40:54.0000] <annevk>
/me is always a little confused about the whole setup

[02:40:55.0000] <tobie>
annevk: np

[02:41:11.0000] <tobie>
annevk: yeah, it's complicated is an understatement.

[02:41:46.0000] <tobie>
annevk: that's what you get when you have crappy data sources.

[02:44:26.0000] <AutomatedTester>
Hi all, I was wondering where I can see what the state of innerText is in terms of standardization

[02:55:54.0000] <annevk>
AutomatedTester: https://github.com/whatwg/html/issues/465

[02:56:47.0000] <AutomatedTester>
annevk: what does it need to get incorporated into a spec?

[02:57:29.0000] <tobie>
Bikeshed's unhappy with the following WebIDL:   Promise<void> start();

[02:57:33.0000] <tobie>
Any idea why?

[02:57:54.0000] <tobie>
(it spits out: FATAL ERROR: IDL SYNTAX ERROR LINE: 5 - skipped: "Promise start()")

[02:58:11.0000] <annevk>
tobie: perhaps it needs to be &lt;void>?

[02:58:24.0000] <AutomatedTester>
tobie: do the <> need escaping?

[02:58:31.0000] <annevk>
AutomatedTester: someone needs to write formal prose

[02:58:50.0000] <annevk>
AutomatedTester: I suspect another hurdle might be lack of agreement between implementations

[02:58:59.0000] <annevk>
AutomatedTester: but I'm not sure if that should block having any spec at all

[02:59:18.0000] <AutomatedTester>
annevk: ok cool

[03:00:19.0000] <tobie>
annevk, AutomatedTester: tried that but forgot to save before running bikeshed. #facepalm

[03:00:26.0000] <AutomatedTester>
tobie: :D

[03:01:04.0000] <tobie>
ty

[03:01:23.0000] <AutomatedTester>
annevk: roc's spec describes the end state that I want, and I want to reference it in WebDriver

[03:01:33.0000] <AutomatedTester>
well... it's the closest thing to what I want

[03:01:56.0000] <AutomatedTester>
whats the best way to reference it?

[03:02:19.0000] <AutomatedTester>
direct to Roc's version? To the html issue?

[03:09:30.0000] <annevk>
AutomatedTester: both, I guess

[03:10:15.0000] <AutomatedTester>
awesome, thanks

[03:43:52.0000] <tobie>
Is there a standard way to define enum members? annevk, you seem to just do: <code>"foo"</code>, I'm seeing slightlyoff do <em>foo</em> instead, etc.

[03:46:00.0000] <annevk>
tobie: I use "<code>foo</code>" in prose

[03:46:12.0000] <annevk>
tobie: I don't see why <em> makes sense to denote a string

[03:46:47.0000] <tobie>
I think slightlyoff uses it to denote the concept behind the string.

[03:47:04.0000] <annevk>
Example?

[03:47:27.0000] <tobie>
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#service-worker-state-attribute

[03:47:46.0000] <annevk>
That spec is written by JakeA and jungkees

[03:48:13.0000] <tobie>
and https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#dfn-state

[03:48:37.0000] <tobie>
yeah, sorry, the original editor was slightlyoff

[03:48:43.0000] <annevk>
That looks loosely copied from what I used to, see e.g., https://xhr.spec.whatwg.org/#dom-xmlhttprequest-readystate

[03:48:56.0000] <annevk>
I no longer think that's useful

[03:49:14.0000] <JakeA>
Cargo-culted I guess

[03:49:25.0000] <tobie>
ok, so you just do <code>"foo"</code>

[03:49:29.0000] <annevk>
Fetch also used to format enums as <i>value</i>

[03:49:39.0000] <annevk>
I recently decided on "<code>value</code>"

[03:49:45.0000] <annevk>
tobie: quotes are not part of the value

[03:50:08.0000] <tobie>
oh. interesting.

[03:50:10.0000] <annevk>
tobie: they only illustrate it's a string, and not a byte sequence

[03:50:24.0000] <annevk>
(or something else altogether, although I'm not sure what that would be)

[03:50:44.0000] <annevk>
e.g. `<code>value</code>` is what I use for HTTP header values

[03:51:00.0000] <tobie>
Not sure such typographical nuance is the clearest way to convey that, but I don't think it matters either.

[03:51:09.0000] <annevk>
since those cannot be represented by strings, but it's still nice to represent them as strings...

[03:51:27.0000] <annevk>
well, there's an explainer of sorts upfront

[03:51:27.0000] <Ms2ger>
Should we document that on the wiki?

[03:52:01.0000] <annevk>
I hope to at some point document the styles in IDL and basically mandate them

[03:52:05.0000] <annevk>
Ms2ger: that might be useful

[03:52:47.0000] <tobie>
I was working off of those so far: https://github.com/tabatkins/bikeshed/blob/master/docs/markup.md#autolink-shortcuts

[03:53:02.0000] <tobie>
+ using <var> for variables.

[03:53:31.0000] <annevk>
There's need to be some spec at the top of the chain that defines these low-level things in excruciating detail

[03:53:48.0000] <annevk>
I think IDL is likely the best fit, but it could be separate I suppose

[03:54:43.0000] <tobie>
Yeah, having consistency across specs for those would be amazing (and actually allows to do a bunch of cool things on top of specs).

[03:55:17.0000] <tobie>
It would be interesting to have some of the HTML infrastructure stuff (like "in parallel") there too.

[03:55:50.0000] <annevk>
Yeah, and the math operators from Encoding (and a bunch of other things from Encoding)

[03:56:12.0000] <annevk>
And things like "ASCII case-insensitive"

[03:56:20.0000] <annevk>
It's a long list

[04:01:51.0000] <tobie>
annevk: Going back to those enums, you don't make each member linkable, do you?

[04:03:49.0000] <annevk>
tobie: no, though in the HTML standard that's sometimes done

[04:04:12.0000] <tobie>
Right, because why should things be consistant.

[04:04:18.0000] <tobie>
:D

[04:04:45.0000] <annevk>
tobie: there's not often a clear place where you define enums, so I think stylistically it's better to not do it

[04:05:27.0000] <annevk>
tobie: I guess you could make IDL the source... dunno

[04:05:52.0000] <annevk>
tobie: IDL wouldn't work well for Fetch, which sometimes has values outside of the range defined by IDL

[04:05:54.0000] <tobie>
annevk: I'm often struggling with which one should be the source.

[04:06:31.0000] <annevk>
Yeah, I think that's why I haven't bothered to make it work

[04:06:41.0000] <tobie>
heh

[04:26:50.0000] <mounir>
annevk: I would like to allow fullscreen to be requested on orientation change (screen orientation api), would you take a pull request that adds this to the spec?

[04:27:52.0000] <annevk>
mounir: if that's what needs to be implemented, yes

[04:28:13.0000] <annevk>
mounir: though a proper fix might be a change to the "user gesture" concept, no?

[04:29:16.0000] <mounir>
annevk: user gesture would still make sense for stuff like autoplay, or starting a WebRTC session, etc.

[04:30:03.0000] <mounir>
annevk: basically, Chrome Security approved going fullscreen on orientation change but they want orientation to be a signal for some stuff, not everything

[04:30:21.0000] <annevk>
I see

[04:30:55.0000] <annevk>
Yeah, please provide a PR, I guess we'll want to ask at least one other implementer to chime in, but sounds reasonable

[04:51:52.0000] <JakeA>
Touch events have made the "user gesture" thing a bit of a nonsense

[04:52:19.0000] <annevk>
JakeA: oh, why?

[04:52:39.0000] <mounir>
JakeA: yes, but that's only on mobile and that's something we are looking into fixing

[04:53:01.0000] <JakeA>
annevk: touch counts as a gesture, so you can do what you want as soon as scroll happens

[04:53:19.0000] <annevk>
Oh, that's not distinguished? Hmm

[04:53:33.0000] <JakeA>
I'm not sure how it can be

[04:53:43.0000] <JakeA>
mounir: ohh, what are the plans?

[04:53:52.0000] <annevk>
Is that why Apple had touch delay?

[04:54:05.0000] <JakeA>
annevk: nah, that was for double-tap-to-zoom

[04:54:49.0000] <JakeA>
touchstart was still instantly a user gesture

[04:55:45.0000] <JakeA>
I've used touchstart to make videos autoplay on mobile, which is annoying as it adds jank to the initial scroll. But it was either that or replace a 400k video with a 5mb gif

[04:56:21.0000] <JakeA>
But I believe both Chrome & WebKit are going to fix this and just allow videos to autoplay

[04:56:36.0000] <annevk>
<video autoplay> does not work?

[04:56:44.0000] <annevk>
I guess I knew that

[04:56:45.0000] <JakeA>
Not on mobile

[04:57:33.0000] <mounir>
JakeA: this isn't really an issue for autoplay, never heard of websites using it on the wild but it's certainly something we should fix before it becomes a problem

[04:58:06.0000] <annevk>
Quite interesting how standards sort of theorized about an eventual smaller screen and different input handlers, but didn't address it sufficiently that it actually ended up being the model when mobile became a thing

[04:58:14.0000] <JakeA>
mounir: true, the preferred solution is h264 decoders written in JS :(

[04:58:28.0000] <mounir>
JakeA: we have plans for that

[04:58:30.0000] <annevk>
And now it's nine years or so since the first iPhone and it's still a mess

[04:58:41.0000] <annevk>
Not super impressive

[05:31:42.0000] <zcorpan>
JakeA: does it work (on mobile) to use an animated gif in <video poster>? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4000

[05:32:12.0000] <JakeA>
zcorpan: I hadn't considered that, but what does it buy you?

[05:32:48.0000] <JakeA>
Works on Chrome android fwiw

[05:32:53.0000] <zcorpan>
seems like a possible workaround to use a reasonably small subset of the video as a poster animated gif on an autoplaying video, to have it start the gif before the user scrolls

[05:33:10.0000] <zcorpan>
and touchstart autostarts the actual video

[06:38:31.0000] <tobie>
JakeA: looking at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#service-worker-registration-update

[06:39:09.0000] <tobie>
JakeA: doesn't step 4 effectively prevent the promise from being returned?

[06:39:10.0000] <JakeA>
zcorpan: maybe, but autoplay would still be better

[06:39:27.0000] <zcorpan>
JakeA: yes for sure

[06:39:39.0000] <JakeA>
tobie: haha, yes I think you're right

[06:40:20.0000] <JakeA>
tobie: if memory serves, I think IDL does the right thing and converts throws to promise rejections, we should be doing that

[06:41:19.0000] <tobie>
JakeA: oh, you would just throw and not care about returning anything in that case?

[06:41:38.0000] <tobie>
Sounds harder for an implementor to get right, no?

[06:42:17.0000] <JakeA>
tobie: maybe I just made that up https://www.w3.org/2001/tag/doc/promises-guide#example-validated-delay

[06:42:33.0000] <tobie>
Asking because I'm in the middle of writing a similar algorithm.

[06:43:05.0000] <JakeA>
tobie: oh wait, I'm right https://www.w3.org/2001/tag/doc/promises-guide#always-return-promises

[06:43:07.0000] <tobie>
"If ms is less than zero, return a promise rejected with a RangeError."

[06:43:13.0000] <JakeA>
first time in 2016

[06:45:11.0000] <JakeA>
https://heycam.github.io/webidl/#es-operations "f the operation has a return type that is a promise type, then…"

[06:45:20.0000] <tobie>
Well, checking that would involve reading some of the prose that's in WebIDL, which my doctor strictly forbids, so no luck.

[06:46:08.0000] <JakeA>
tobie: in short, if your algo throws and your return type is a promise, it auto-wraps the error in Promise.reject(err) and returns that

[06:46:16.0000] <annevk>
If as an implementer you do not read IDL you are also out of luck though

[06:46:55.0000] <tobie>
ok, I'll just throw stuff around.

[06:46:59.0000] <tobie>
:)

[06:47:10.0000] <annevk>
We should have made IDL establish some kind of convention though since I think specifications now do both

[06:47:20.0000] <annevk>
Some reject the promise, otherwise happily throw

[06:47:24.0000] <annevk>
others*

[06:49:33.0000] <tobie>
That seems like a recurring theme.

[06:53:06.0000] <annevk>
Someone needs to find some time

[06:57:09.0000] <tobie>
annevk: I've been trying to sell documenting these things to a bunch of clients in the past. Have been unsuccessful so far.

[06:57:48.0000] <annevk>
tobie: bah

[07:03:00.0000] <Ms2ger>
/me wonders if https://drafts.csswg.org/cssom-view/#the-html-body-element should consider frameset

[07:06:42.0000] <annevk>
Trying to define "shadow-host-including tree order" is no fun

[07:12:10.0000] <annevk>
shadow-root-including, even

[07:18:11.0000] <smaug____>
anyone recall where rniwa's tests for rootNode are

[07:18:22.0000] <smaug____>
some pr in github I think

[07:19:00.0000] <annevk>
smaug____: obvious place would be web-platform-tests, and indeed, https://github.com/w3c/web-platform-tests/pull/2665

[07:19:12.0000] <smaug____>
thanks

[07:21:39.0000] <jgraham>
smaug____: Oops, didn't see that rniwa had updated that.

[07:22:11.0000] <jgraham>
Would be nice to get it squashed before merging

[08:03:52.0000] <Domenic>
botie where are you

[08:03:55.0000] <tobie>
When do you decide to name an algorithm and reference it from a method? All the time, or just when you call said algorithm all the time?

[08:03:56.0000] <Domenic>
MikeSmith ^

[08:04:08.0000] <annevk>
Domenic: I guess I'll wait until we have [[PlatformBrand]] and then fix that issue

[08:04:18.0000] <Domenic>
annevk: sounds good

[08:04:27.0000] <tobie>
Hey Domenic -- tried to fix your Specref woes to no avail.

[08:04:27.0000] <Domenic>
tobie: when it has more than one caller, including in other specs, generally.

[08:04:36.0000] <Domenic>
tobie: yeah, I saw :(

[08:04:50.0000] <tobie>
yeah, the codebase is dreadful.

[08:05:27.0000] <tobie>
which I'm to blame for.

[08:06:27.0000] <tobie>
Domenic: ty, had forgotten about the "other specs" aspect which is critical for the sensor work.

[08:08:00.0000] <Ms2ger>
annevk, you know if there's a reason for language to be nullable at https://html.spec.whatwg.org/multipage/#navigatorlanguage ?

[08:09:14.0000] <Domenic>
Ms2ger: fascinating...

[08:09:51.0000] <Domenic>
/me remembers how Web IDL return values are useless and redundant

[08:10:24.0000] <annevk>
Ms2ger: no

[08:10:29.0000] <Ms2ger>
They're pretty damn useful

[08:10:40.0000] <Ms2ger>
annevk, want an issue?

[08:11:08.0000] <annevk>
Ms2ger: I guess, would be nice if we could change that

[08:11:53.0000] <Ms2ger>
https://github.com/whatwg/html/issues/881

[08:13:36.0000] <Domenic>
"These interfaces are defined separately so that other specifications can re-use parts of the Navigator interface."

[08:13:39.0000] <Domenic>
like what?

[08:13:56.0000] <Domenic>
Probably WorkerNavigator

[08:14:00.0000] <Domenic>
But that's the same specification

[08:15:47.0000] <Ms2ger>
Used not to be

[08:15:49.0000] <annevk>
Domenic: maybe a leftover from when Hixie_ used to split workers out

[08:16:20.0000] <annevk>
Domenic: I would somewhat prefer a single Navigator interface with better use of [Exposed] for individual members

[08:16:34.0000] <Ms2ger>
But self.WorkerNavigator

[08:16:55.0000] <annevk>
Yeah, that kinda kills it

[08:17:44.0000] <annevk>
I guess we could just do interface WorkerNavigator {}; WorkerNavigator implements Navigator; and not expose Navigator in Worker, just its members...

[08:18:39.0000] <Domenic>
meh

[08:19:02.0000] <Ms2ger>
Interfaces on the rhs of implements? Meh

[08:19:23.0000] <annevk>
I guess I'll stop caring

[08:22:04.0000] <tobie>
So I have a dfn of sensor which is the underlying sensor (https://w3c.github.io/sensors/#sensor) and I have a WebIDL Sensor Interface. Now when I have an algorithm that talks about an instance of Sensor, it seems natural to use <var>sensor</var> for it which is confusing. How should I go about that?

[08:23:53.0000] <tobie>
s/for it which/for it, which/

[08:24:20.0000] <Domenic>
tobie: I ran into this yesterday and decided to merge the concepts so that I can just talk about the Sensor object.

[08:24:28.0000] <tobie>
Commas are kind of useful.

[08:24:38.0000] <Domenic>
(In my case it was CustomElementsRegistry objects. HTML also does this for Window and Document objects.)

[08:24:45.0000] <Ms2ger>
Alternatively, concept-sensor

[08:24:58.0000] <Domenic>
On the other hand annevk does things like URL objects having a url, which is fine.

[08:25:05.0000] <tobie>
The problem is I have one underlying sensor which can have many associated sensor objects

[08:25:12.0000] <Domenic>
In my case I just found that I was constantly doing "the CustomElementRegistry's custom element registry"

[08:25:20.0000] <Domenic>
Sounds like a useful distinction then yeah

[08:25:59.0000] <annevk>
tobie: I'd only disambiguate the variable name if it was important

[08:26:11.0000] <annevk>
tobie: e.g., actualSensor and sensorInstance

[08:26:12.0000] <tobie>
so like "s"?

[08:26:20.0000] <tobie>
oh, better. :)

[08:27:01.0000] <tobie>
Thanks folks, that's super helpful.

[08:27:21.0000] <annevk>
tobie: often though in an algorithm you would just reference "this" (aka context object until we rename that)

[08:27:31.0000] <tobie>
oh

[08:27:44.0000] <tobie>
do you have examples of that handy?

[08:27:54.0000] <annevk>
tobie: and then context object's sensor would be unambiguous, since context object is the instance, and sensor is the shared sensor

[08:28:12.0000] <annevk>
tobie: https://dom.spec.whatwg.org/#dom-element-shadowroot

[08:28:27.0000] <annevk>
tobie: (lots of specifications reuse the "context object" concept from DOM)

[08:31:40.0000] <tobie>
I think using sensorInstance or the like will make the whole thing more readable. Anyway, easy to change later on as long as I'm using two distinct words.

[08:32:47.0000] <Domenic>
We've been using "this `Sensor` object" in new specs

[08:33:20.0000] <annevk>
True, I don't really like that either since it's too long

[08:34:04.0000] <annevk>
We should just be able to use this or a variable that we get to name since IDL invokes the specification-defined algorithm directly with this as the first argument (this is what I really want)

[08:38:44.0000] <gsnedders>
/me wonders if anyone knows much about BitTorrent here

[08:41:06.0000] <gsnedders>
Does the DHT contain everything that the torrent metadata file does?

[08:45:10.0000] <annevk>
Doing Fullscreen's shadow DOM integration today is too much... but I'll drop utf-16's encoders, much more satisfying way to end the day too

[09:06:27.0000] <zcorpan>
anyone who likes security and privacy sections pls see https://www.w3.org/Bugs/Public/show_bug.cgi?id=29533 (for cssom-view)

[09:06:43.0000] <zcorpan>
/me *poff*

[09:20:07.0000] <TabAtkins>
annevk: It was bikeshed. SpecRef is only for biblio references, not autolinks.  Fixed it for you.

[09:21:02.0000] <TabAtkins>
annevk: enum values are now dfn'd by Bikeshed too, so they can be autolinked.

[09:21:31.0000] <TabAtkins>
Style is like <a enum-value>"foo"</a>.

[10:02:12.0000] <annevk>
https://twitter.com/FirefoxNightly/status/709760092648841216 Fetch is still very misunderstood by some 😟

[10:02:30.0000] <annevk>
(In this case the writer of that tweet.)

[10:07:14.0000] <caitp>
maybe you should tweet about it to market it better

[10:08:06.0000] <caitp>
with gretchen from Mean Girls as the mascot

[10:08:13.0000] <annevk>
fair

[10:08:23.0000] <caitp>
catch phrase "That's so fetch!"

[10:17:09.0000] <wanderview>
annevk: wow

[10:18:05.0000] <annevk>
wanderview: yeah, I replied per caitp's advice

[10:19:58.0000] <caitp>
the only thing missing is a lacey chabert gif with a silly caption

[10:45:26.0000] <annevk>
smaug____: have you reviewed https://w3c.github.io/webcomponents/spec/shadow/#extensions-to-event-interface?

[10:45:59.0000] <annevk>
smaug____: I was wondering whether putting those flags on event objects was the way to go, or whether they should be parameters for the dispatch algorithm

[10:46:13.0000] <annevk>
smaug____: I guess putting them on event objects is more consistent with how event objects work today

[10:47:17.0000] <smaug____>
I haven't reviewed that

[10:47:49.0000] <smaug____>
those flags feel a bit odd

[10:47:55.0000] <smaug____>
why would JS need to know about them

[10:48:25.0000] <annevk>
I think when I proposed this to hayato I suggested flags that the dispatcher would pass to dispatch

[10:48:40.0000] <annevk>
But it seems he went with a different design

[10:51:40.0000] <smaug____>
I wonder why

[10:52:04.0000] <smaug____>
is there some use case where those flags are needed in JS

[10:52:30.0000] <smaug____>
so far I haven't heard of anyone needing them with XBL stuff

[10:53:19.0000] <annevk>
smaug____: does Gecko store them on the event object or pass them as part of dispatch?

[10:54:09.0000] <smaug____>
annevk: so this scoped is for example for mouseout/over events?

[10:55:20.0000] <annevk>
smaug____: it's not defined very well at the moment, but see https://w3c.github.io/webcomponents/spec/shadow/#event-paths

[10:55:45.0000] <annevk>
I sorta thought everything Shadow DOM was reviewed at this point

[10:56:18.0000] <smaug____>
really?

[10:56:31.0000] <Ms2ger>
Ha

[10:56:59.0000] <smaug____>
"abort, error, select, change, load, loadedmetadata, reset, resize, scroll and selectstart."

[10:57:02.0000] <annevk>
smaug____: well yeah, guess I'm glad I haven't landed the event stuff in DOM yet

[10:57:29.0000] <smaug____>
so that is missing stuff like mouseover/out within shadow DOM. or perhaps that happens in dispatch.

[10:57:31.0000] <smaug____>
looking

[10:57:55.0000] <annevk>
They don't define dispatch, nobody does

[10:58:04.0000] <annevk>
😟

[10:58:21.0000] <smaug____>
hmm, meeting

[10:58:33.0000] <smaug____>
anyhow, in XBL mouseover/out are handled during event path creation

[10:59:04.0000] <annevk>
smaug____: interesting...

[10:59:07.0000] <smaug____>
and some other stuff use very internal flags so that the event is still dispatched to chrome

[10:59:17.0000] <smaug____>
but nothing of that is exposed to JS

[10:59:20.0000] <annevk>
smaug____: file github.com/w3c/webcomponents/issues/new maybe on exposing these properties and such?

[10:59:30.0000] <smaug____>
yeah

[10:59:52.0000] <annevk>
I'll triage tomorrow / maybe figure something out

[11:19:48.0000] <tobie>
TabAtkins: thanks.

[11:20:02.0000] <tobie>
TabAtkins: for the enum values.

[11:52:41.0000] <smaug____>
annevk: filed. silly bug title. oh well

[16:10:49.0000] <MikeSmith>
Domenic: botie is back

[16:34:38.0000] <gsnedders>
WebIDL help: given the OrderedMap example in it, how would map.apple ever return undefined? shouldn't it just return null? where does the null from the get() become an undefined?


2016-03-16
[01:16:55.0000] <philipj>
annevk, Domenic, about CDATASection, that's a removal I think *could* work out, but it wouldn't be completely purged because https://www.chromestatus.com/metrics/feature/timeline/popularity/113 so I'm a bit on the fence

[01:18:02.0000] <philipj>
Domenic is right that it'd break some serialization tests, but that's not really the problem, the problem would be to get everyone to care enough to actually make this change. Less valuable than Attr simplification I think.

[01:19:16.0000] <philipj>
annevk: I'll add the ? to insertAdjacentElement's return type in Blink. Note that this doesn't actually change any behavior, the nullability of return types doesn't change the generated code. (so if things that shouldn't return null do, there's no assert there)

[01:21:16.0000] <annevk>
philipj: I figured that was what was going on

[01:21:45.0000] <annevk>
philipj: Gecko uses the return values to inform the JIT aiui

[01:22:02.0000] <annevk>
return types*

[01:22:34.0000] <philipj>
hmm, so if something that shouldn't return null does, it would crash, most likely?

[01:26:18.0000] <annevk>
philipj: I guess that would be problematic, I don't know the specifics

[01:26:58.0000] <annevk>
philipj: WebAssembly folks also have some ideas around type-informed optimizations

[01:27:15.0000] <philipj>
oh well, I hope that when the return types are all per spec in Blink, one might add asserts to find some lies

[01:27:21.0000] <annevk>
philipj: basically skipping a whole lot of the checks IDL does to guarantee you have objects of the proper brand

[01:27:41.0000] <annevk>
Should speed up things a little too if that works out

[01:28:22.0000] <annevk>
JakeA: you know you're feeding a troll, right?

[01:30:42.0000] <JakeA>
annevk: yeahhhh. I want going to reply, but I saw his post getting shared on Twitter so figured I'd see how far a reasonable response would get

[01:30:57.0000] <JakeA>
But you're right it's not helping

[01:32:08.0000] <annevk>
Been a while since I saw someone using all caps words (apart from constants)

[01:37:15.0000] <annevk>
https://w3c.github.io/DOM-Parsing/ hasn't been maintained since June 2014, ugh

[01:50:13.0000] <tobie>
TabAtkins: are the enum values documented anywhere?

[02:18:02.0000] <tobie>
In one of the algorithm steps in the sensor spec, I need to iterate over a set of sensor instances to resolve promises and fire events.

[02:18:04.0000] <tobie>
In the polyfill, I clone the set before doing so, to avoid unwanted side effects if one of the handler actually removes a sensor from the set.

[02:18:14.0000] <tobie>
Is there spec language to describe this?

[02:20:02.0000] <tobie>
For ref, here are the polyfill lines: https://github.com/w3c/sensors/blob/cfc3932/polyfills/geolocation.js#L124-L126

[02:37:02.0000] <annevk>
zcorpan: do you happen to know if we have a test for https://github.com/whatwg/html/issues/842?

[02:43:46.0000] <zcorpan>
annevk: ./Secure-Close-1005-verify-code.htm:            assert_equals(evt.code, 1005, "CloseEvent.code should be 1005");

[02:45:30.0000] <zcorpan>
though wss: might not work, on w3c-test.org at least

[02:46:03.0000] <annevk>
zcorpan: that tests what the server transmitted, not what the client transmitted

[02:46:21.0000] <zcorpan>
annevk: the server echos the client's code

[02:46:40.0000] <zcorpan>
or that seems to be the intent

[02:46:42.0000] <annevk>
zcorpan: so by default the client transmits 1005, a code developers cannot set?

[02:47:30.0000] <zcorpan>
i don't know what browsers do or if this test is correct per spec

[02:47:39.0000] <zcorpan>
i think this test was written by MS

[02:47:58.0000] <zcorpan>
the tests i wrote predated close codes

[02:48:31.0000] <annevk>
Hmm, they don't seem great

[02:50:01.0000] <annevk>
Okay, so WSP has internal contradictions

[02:51:38.0000] <zcorpan>
"If this Close control frame contains no status code, _The WebSocket Connection Close Code_ is considered to be 1005." -- though this doesn't mean that close() should send 1005

[02:52:22.0000] <zcorpan>
in fact 1005 must not be sent explicitly

[02:52:31.0000] <annevk>
close() invokes https://tools.ietf.org/html/rfc6455#section-7.1.2 which requires a /code/

[02:52:36.0000] <zcorpan>
right

[02:52:52.0000] <annevk>
Though it seems you can transmit an empty Close frame (without body) too

[02:52:57.0000] <zcorpan>
it seems to me close() should be equivalent to close(1000)

[02:53:00.0000] <annevk>
Maybe clients do that?

[02:53:28.0000] <annevk>
And just ignore that the protocol requires /code/ not to be optional (since it describes elsewhere that it is)

[02:56:22.0000] <annevk>
zcorpan: emailed hybi

[02:56:37.0000] <annevk>
zcorpan: copied you and tyoshino

[03:04:27.0000] <annevk>
Why does The WebSocket Protocol use both "Close message" and "Close frame"?

[03:10:04.0000] <zcorpan>
no idea. i assume they mean the same thing (and Close frame is the correct one)

[03:11:35.0000] <annevk>
zcorpan: hmm, the spec says that messages consist of one or more frames

[03:11:54.0000] <annevk>
zcorpan: but I'm not sure if it actually uses that terminology consistently

[03:12:58.0000] <zcorpan>
http://w3c-test.org/websockets/closing-handshake/003.html is a simple test for close(), i'll inspect it with packetpeeper

[03:13:51.0000] <zcorpan>
annevk: ah yeah, but iirc you're not allowed to fragment close into multiple frames

[03:15:34.0000] <zcorpan>
"Control frames themselves MUST NOT be fragmented."

[03:26:56.0000] <zcorpan>
well... i've found the packet that contains the close frame from the client but i can't make much sense of it, i can't seem to get the payload itself (only in a form where it's converted to text in a lossy way)

[03:30:54.0000] <zcorpan>
annevk: http://imgur.com/1dS4le4

[03:31:51.0000] <zcorpan>
annevk: this is with Nightly with closing-handshake/003.html, the last PSH packet from the client

[03:32:57.0000] <annevk>
zcorpan: hmm, there's some kind of obfuscation going on, right?

[03:35:03.0000] <annevk>
zcorpan: not really sure what to make of that either

[03:37:59.0000] <annevk>
zcorpan: in Chrome I get "e.wasClean expected true but got false" for that test

[03:38:34.0000] <zcorpan>
annevk: don't think so, the websocket frame header shouldn't be obfuscated i think. it's just that this is the whole TCP packet and i don't know how to parse TCP in my head :-)

[03:39:20.0000] <annevk>
I wonder why Firefox doesn't have debugging for WebSocket

[03:40:30.0000] <zcorpan>
chrome's devtools can inspect messages but not close frames last i checked

[03:40:39.0000] <annevk>
https://addons.mozilla.org/en-US/firefox/addon/websocket-monitor/

[03:41:34.0000] <annevk>
zcorpan: with that addon I get disconnected, code 1005

[03:45:02.0000] <annevk>
zcorpan: that addon doesn't really log the close reason though, if I provide one, but it does allow me to disconnect with 1000

[04:11:38.0000] <zcorpan>
i suppose the TCP payload must be the trailing 6 bytes, thus F1 86 4A

[04:13:39.0000] <zcorpan>
er

[04:14:47.0000] <zcorpan>
88 80 CC F1 86 4A

[04:23:46.0000] <zcorpan>
and from what i can tell from the WebSocket framing, that means the payload length is 0 and therefore no close code is sent

[04:24:39.0000] <zcorpan>
/me wipes his forehead

[04:39:11.0000] <zcorpan>
in Chrome the close frame also has no payload (though Chrome fails the test for .wasClean; not sure why, the close handshake looks OK to me)

[04:43:26.0000] <zcorpan>
WebKit also no payload (and it passes the test)

[04:45:15.0000] <zcorpan>
.code returns 1005 in webkit and gecko; 1006 in chrome

[05:16:33.0000] <smaug____>
Ms2ger: since I don't understand github jargon, https://github.com/w3c/web-platform-tests/pull/2665 means the tests are now in wpt?

[05:31:12.0000] <smaug____>
I guess so

[05:31:17.0000] <smaug____>
silly me

[07:02:57.0000] <annevk>
mkwst: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27852 waits for a reply from you

[07:14:14.0000] <mkwst>
Replied, sorry I missed it.

[07:17:47.0000] <MikeSmith>
annevk: I removed the HISTORICAL- prefix from a bunch more bugzilla components. So hopefully that will un-break some links. But if later you notice any specific ones I missed, lemme know

[07:18:39.0000] <mkwst>
annevk: If you want that in Fetch, let's just move the bug to GitHub and I'll try to send you a PR later in the week. If you want in HTML, then maybe I'll let Domenic write a PR because HTML is huge. :)

[07:21:29.0000] <annevk>
Domenic: what do you think? ^

[07:21:59.0000] <annevk>
/me doesn't care strongly about the layering, and Fetch already has some MIME type blocking

[07:22:51.0000] <annevk>
mkwst: Domenic: actually, maybe Fetch is better if we just want to treat image MIME types as a network error

[07:23:30.0000] <annevk>
mkwst: Domenic: aaah, starting to second guess, HTML has some MIME type checks for <script> too now, with <script type=module>

[07:23:36.0000] <annevk>
/me drops mic

[07:23:52.0000] <annevk>
MikeSmith: ta

[07:24:46.0000] <Domenic>
annevk: happy to let Fetch handle that. It seems potentially better there. Based on destination etc.

[07:28:33.0000] <annevk>
Okay, mkwst, PR Fetch then 😃

[07:33:15.0000] <annevk>
TabAtkins: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17632 styling of <li> in terms of CSS, is that possible yet?

[08:56:26.0000] <TabAtkins>
annevk: start and value, yes.  reverse, no.

[08:58:23.0000] <TabAtkins>
Handling value required the new counter-set property from the Lists spec, which I think Gecko implements.

[09:15:48.0000] <TabAtkins>
tobie: In the autolinking section of the docs, like all the other linking types.

[09:17:21.0000] <tobie>
TabAtkins: oh, right, saw it now.

[09:24:08.0000] <annevk>
TabAtkins: should HTML define some kind of magical value for something in the rendering section?

[09:24:23.0000] <annevk>
TabAtkins: similar to xxx-large

[09:24:43.0000] <TabAtkins>
Say that, in the reverse case, implementations must act as if counter-reset were set to XXX value.

[09:30:57.0000] <annevk>
TabAtkins: I guess that works, though we might still run into trouble with getComputedStyle

[09:32:09.0000] <annevk>
TabAtkins: anyway, added your suggestion to the bug, thanks

[09:41:19.0000] <gabr13l>
Hello WHATWG crew! o/

[10:43:10.0000] <annevk>
Does anyone know if junov ever hangs out on IRC?

[10:43:21.0000] <annevk>
There's a bunch of legacy <canvas> bugs they might be interested in

[11:31:09.0000] <annevk>
TabAtkins: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17770 is another <li> thingie

[11:31:16.0000] <annevk>
TabAtkins: awaiting attention from you

[11:32:28.0000] <annevk>
JakeA: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27875 is awaiting an answer from you

[11:50:46.0000] <Domenic>
Ahhhhh whaaaaat environment settings objects are not 1:1 with Windows whaaaat

[12:10:10.0000] <mkwst>
TabAtkins: Once you're done doing whatever annevk wants you to do, tell me all about how easy it must be by now to magically publish daily drafts to /TR via Bikeshed and Whatever They've Called Their Tool(tm). :)

[12:10:29.0000] <mkwst>
(Also, thanks for fixing Bikeshed this morning. :) )

[12:14:29.0000] <annevk>
Domenic: 😭

[12:14:57.0000] <annevk>
Domenic: not looking forward to reading about that tomorrow

[12:16:00.0000] <Domenic>
annevk: it explains why nothing gets stored on settings objects, and instead they all have algorithms that grab things from places...

[12:16:32.0000] <Domenic>
Until I messed up and did module map :(

[14:13:11.0000] <TabAtkins>
annevk: That bug is still pending me updating Lists and getting the WG to sign off on it.

[14:13:28.0000] <TabAtkins>
Which I plan to do in the next few months, but I've said that for about two years, so who knows whether I"ll actually achieve it.

[15:02:26.0000] <TabAtkins>
mkwst: It's not easy *quite* yet, but I *think* all the necessary bits are in place, I just need to fiddle with them and make them work.

[15:58:30.0000] <tobie>
Probably a very noob question, but should you always queue a task to dispatch events or are there legitimate cases where you shouldn't do so?

[15:59:21.0000] <jgraham>
Certianly not all existing events queue a task

[15:59:57.0000] <jgraham>
Legitimately it makes sense during navigation and so on, I think

[16:03:01.0000] <tobie>
mmm

[16:03:36.0000] <tobie>
While on the topic, I guess there's no simple way to polyfill "queue a task"

[16:06:57.0000] <jgraham>
Sure there is

[16:07:10.0000] <jgraham>
Use postMessage

[16:09:23.0000] <tobie>
jgraham: oh, cool. Thanks

[16:27:52.0000] <tobie>
jgraham: arg, that's more complicated than I initially expected. Giving seTimeout(fn, 0). Probably sufficient for my needs.

[16:31:38.0000] <jgraham>
k

[16:35:58.0000] <tobie>
jgraham: was looking at this: https://github.com/YuzuJS/setImmediate/blob/master/setImmediate.js


2016-03-17
[22:18:10.0000] <annevk>
hayato: thanks for cleaning up past shadow DOM issues!

[01:43:34.0000] <tobie>
Hi all--in Bikeshed, does anyone know how I can both use markdown and use "algorithm" attributes on containers?

[01:44:10.0000] <tobie>
I'm getting: FATAL ERROR: Line 567 isn't indented enough (needs 1 indent) to be valid Markdown

[02:24:31.0000] <tobie>
Answering my own question: you don't need to indent markdown outside of containers, but you somehow do when it's inside a container. (Also know as: read the error message properly.)

[02:46:37.0000] <zcorpan>
tobie: i think you can remove indentation in either case if you like

[02:47:04.0000] <tobie>
zcorpan: oh, through a meta property or something?

[02:47:42.0000] <tobie>
I'm having the hardest time linking to algorithms. Any pointers?

[02:47:43.0000] <zcorpan>
tobie: no. i'm guessing you used something like 1 or 2 spaces indentation when you added the container?

[02:48:00.0000] <zcorpan>
tobie: use <dfn> and <a>?

[02:48:04.0000] <tobie>
zcorpan: no, there was no spacing at all.

[02:48:22.0000] <zcorpan>
tobie: huh. ok then i don't know

[02:49:25.0000] <tobie>
zcorpan: well, I'm using the algorithm attribute on the section title where the attribute is defined.

[02:49:40.0000] <tobie>
sorry:

[02:49:54.0000] <tobie>
 zcorpan: well, I'm using the algorithm attribute on the section title where the algorithm is defined.

[02:50:50.0000] <zcorpan>
algorithm="" is to scope <var>s so bikeshed can complain if you use a var only once in an algorithm, it doesn't help with linking

[02:51:17.0000] <zcorpan>
you can link to sections or <dfn>s

[02:51:26.0000] <tobie>
mmm. that's unfortunate.

[02:52:29.0000] <tobie>
Is the sole point of naming the algorithm for error reporting, then?

[02:52:37.0000] <zcorpan>
yeah

[02:52:46.0000] <tobie>
gotcha

[02:52:57.0000] <tobie>
thanks!

[02:53:27.0000] <zcorpan>
it works about as well to just say <h3 algorithm> if you don't want to spend time naming things

[02:54:36.0000] <tobie>
right.

[02:56:30.0000] <zcorpan>
TabAtkins: when should <dfn abstract-op> be used?

[02:58:35.0000] <tobie>
It's weird though, because that makes things sort of redundant.

[02:58:42.0000] <tobie>
You have to do something like:

[02:59:05.0000] <tobie>
<h3 algorithm>Update State</h3>\n<p>The <dfn>Update State</dfn> algorithm…

[03:08:35.0000] <tobie>
zcorpan: so I'm now referencing the "update state" (https://w3c.github.io/sensors/#update-state) algorithm from within the "update reading" algorithm (https://w3c.github.io/sensors/#update-reading), and of course that creates an extra id (https://w3c.github.io/sensors/#update-state0) that points to the dfn.

[03:09:07.0000] <tobie>
I'm sure there's a more elegant solution to this issue, but I'm struggling to figure out what it should be.

[03:14:05.0000] <zcorpan>
tobie: HTML spec sometimes uses dfn in a heading

[03:14:55.0000] <zcorpan>
maybe try it and see what bikeshed makes of it :-)

[03:18:27.0000] <tobie>
zcorpan: https://w3c.github.io/sensors/#update-state

[03:18:58.0000] <tobie>
Updated only the first one so you could compare.

[03:19:34.0000] <tobie>
I think I'm going to go with that.

[04:16:28.0000] <mkwst>
tobie: `<h3 algorithm dfn>Update State</h3>` should define the term in the heading.

[04:16:44.0000] <tobie>
mkwst: oh! Wow.

[04:19:17.0000] <tobie>
Now _that_ is exactly what I was looking for.

[04:20:20.0000] <mkwst>
Bikeshed does basically everything. Something those things are less well documented than others, though. :)

[05:18:32.0000] <tobie>
Pondering whether a sensor event should move to an "idle" state after emitting an error event, have a specific "errored" state, or continue expecting more data from the underlying HW sensor.

[05:26:34.0000] <annevk>
tobie: depends a bit on the HW I guess

[05:27:21.0000] <tobie>
annevk: yeah, that what makes me uncomfortable, I guess.

[05:28:05.0000] <annevk>
tobie: does HW fail sometimes and then goes on or fail more permanently

[05:28:51.0000] <tobie>
So that would imply having a way to distinguish these failure "types"

[05:29:09.0000] <annevk>
tobie: I guess if you are considering switching states it's a bit more permanent than just a wrong value/read?

[05:30:03.0000] <annevk>
tobie: maybe, if we want to expose that amount of detail; also tells a lot about the device

[05:30:25.0000] <annevk>
/me is just brainstorming, fwiw

[05:30:50.0000] <tobie>
annevk: brainstorming is what I need here, so that's perfect.

[05:31:35.0000] <tobie>
annevk: so I transition state from "activating" to "active" when the first reading is received.

[05:32:15.0000] <tobie>
annevk: in the meantime I can get a "permission denied" error, which should clearly shut the sensor off.

[05:32:55.0000] <annevk>
Well, not the HW per se, some other window might be using it

[05:33:32.0000] <tobie>
annevk: oh, yeah absolutely. Granted User Agent can't really access the sensors themselves on most devices

[05:34:58.0000] <annevk>
Hopefully long term the UA is the OS

[05:35:13.0000] <tobie>
annevk: heh

[05:35:25.0000] <tobie>
Good point though.

[05:36:18.0000] <annevk>
But yeah, I guess it depends on what the HW does or what existing OS libs provide, prolly varies per sensor and over time 😊

[05:37:44.0000] <tobie>
annevk: ok, so let's admit we can split errors into two categories. Terminal ones and others.

[05:38:14.0000] <tobie>
Terminal ones imply that sensor access is definitely severed.

[05:38:30.0000] <tobie>
Others that it might be a temporary glitch.

[05:40:03.0000] <annevk>
I think state === error is what you want

[05:40:12.0000] <tobie>
Terminal errors should: emit an error, reject the start() promise if that promise hasn't been resolved already, and change tge state back to "idle" (or "errored")

[05:40:48.0000] <annevk>
In the "permanent" failure cases

[05:40:56.0000] <tobie>
annevk: ok so you would add an "error" state for the permanent failure case.

[05:41:30.0000] <tobie>
Or "errored"?

[05:41:40.0000] <tobie>
yikes.

[05:41:48.0000] <annevk>
Yeah, if you dispatch a special event it's generally worth observing

[05:42:19.0000] <annevk>
On the object too, otherwise you have to keep track yourself

[05:42:32.0000] <annevk>
Bit ugly eg with XHR

[05:42:54.0000] <tobie>
Oh, do you mean an "error" attribute?

[05:43:12.0000] <tobie>
/me is confused.

[05:43:27.0000] <annevk>
I meant in terms of state

[05:43:47.0000] <tobie>
so: sensor.state === "error"

[05:44:00.0000] <annevk>
Detailed error info is never v0-1

[05:44:00.0000] <annevk>
Yeah

[05:44:31.0000] <tobie>
yeah, I guess that's another good point.

[05:44:50.0000] <annevk>
error is easier than errored, but I guess you already noticed 😊

[05:46:34.0000] <tobie>
annevk: sure, it's just weird to have a noun in the middle of adjectives and verbal actions.

[05:47:21.0000] <tobie>
Should that state imply the sensor object is good to throw away?

[05:47:43.0000] <tobie>
annevk: or would it be roughly the same as "idle"

[05:47:59.0000] <tobie>
i.e. you can give it another try?

[05:48:43.0000] <annevk>
I would reject start I guess

[05:48:47.0000] <annevk>
If HW failure, new thing would fail too

[05:49:21.0000] <tobie>
right, but permissioning might change

[05:50:22.0000] <annevk>
Hmm, not sure then

[05:50:28.0000] <annevk>
Biab

[06:11:18.0000] <annevk>
tobie: so how do permissions work here? Maybe start() can just return false and you return to idle?

[06:11:33.0000] <annevk>
tobie: not sure if coupling permission errors and HW errors is best

[06:13:25.0000] <annevk>
jochen__: if it's not too much trouble, it would be great to have Blink's origin setup as a reply to https://www.w3.org/Bugs/Public/show_bug.cgi?id=27378#c39

[06:13:41.0000] <annevk>
jochen__: that and your review on the origin PR, pretty please

[06:14:25.0000] <tobie>
annevk: well, start's return promise is going to be rejected if the permission is denied

[06:15:55.0000] <tobie>
annevk: I would imagine other fatal errors to do the same.

[06:16:40.0000] <annevk>
tobie: so both are exceptional?

[06:17:00.0000] <annevk>
tobie: as in, if start() were synchronous you'd throw an exception for these cases?

[06:17:43.0000] <tobie>
yes, I mean if the sensor doesn't work or can't be accessed, it should just throw,

[06:21:18.0000] <tobie>
I guess I'm going to distinguish between fatal and nonfatal exceptions.

[06:24:46.0000] <tobie>
annevk: one last thing: what's your take on letting the API consumer control timeouts? Seems fetch doesn't have that ability.

[06:25:20.0000] <Ms2ger>
XHR does, no?

[06:26:01.0000] <tobie>
annevk: so basically something like: sensor.start(3000).then(...) or new Sensor({timeout: 3000}).start()...

[06:27:29.0000] <tobie>
Ms2ger: indeed

[06:29:46.0000] <annevk>
tobie: I would wait for cancelable promises

[06:30:43.0000] <annevk>
tobie: until that happens folks can create some kind of wrapper with setTimeout and eat up the extra cost of something being allocated they don't need

[06:31:09.0000] <annevk>
tobie: sensors needing cancelable promises will only help further them being created

[06:32:00.0000] <tobie>
annevk: mmm.

[06:33:48.0000] <tobie>
I'm not too sure what cancellable promises would give me in this case.

[06:35:42.0000] <annevk>
tobie: the way a timeout works is that it cancels the activity after a period of time

[06:36:00.0000] <annevk>
tobie: the activity is represented by the promise

[06:36:11.0000] <annevk>
tobie: we have a timer, what we lack is the cancel primitive

[06:36:51.0000] <tobie>
annevk: oh, so you're suggesting that this should not be an error.

[06:37:00.0000] <annevk>
tobie: if you make a timeout cause rejection, your API will likely be out-of-sync with fetch() where it will likely cause cancelation

[06:37:34.0000] <annevk>
tobie: it's a little unclear, but I wouldn't add the feature until we know

[06:37:59.0000] <tobie>
annevk: OK, what's the timeline for that?

[06:38:04.0000] <tobie>
roughly

[06:38:34.0000] <annevk>
tobie: Domenic gave an ETA of 2 months, but custom elements came in the way, and he's also working on JavaScript Zones, but that seems smallish

[06:38:47.0000] <annevk>
tobie: so, 6-12 months? :-p

[06:38:51.0000] <tobie>
:D

[06:41:00.0000] <tobie>
annevk: what's your plan for distinguishing timeout errors coming from the network layer from consumer timeout-based cancellation?

[06:43:57.0000] <annevk>
tobie: you mean from the UA? No plan as of yet

[06:44:36.0000] <annevk>
tobie: is a network error and prolly hard to change

[06:45:04.0000] <tobie>
annevk: right, so you will have both, then?

[06:45:59.0000] <tobie>
annevk: currently calling stop() while start's promised is unresolved throws an Abort error, so maybe I should defer that too, no?

[06:46:17.0000] <tobie>
* promise

[06:46:47.0000] <tobie>
Whereby "defer" I mean "wait for cancellable promises to be shipped"

[06:49:53.0000] <annevk>
tobie: yeah, maybe ask JakeA / Domenic

[06:50:07.0000] <annevk>
tobie: we'll have developer-controlled timeouts at some point

[06:50:20.0000] <tobie>
Well, you just did for me. :)

[06:51:12.0000] <annevk>
tobie: I could even imagine cancelablePromise.time(100) or some such, but takes a long time for convenient methods to get added to JavaScript

[06:51:20.0000] <annevk>
convenience*

[07:26:21.0000] <wanderview>
annevk: I was just in a meetup this week where a developer said "don't use promises, use observables because they can be canceled"

[07:33:33.0000] <tobie>
push-api "defines" a PermissionDeniedError DOM Exception. Is that going to make its way into WebIDL or should I use something else?

[07:34:21.0000] <tobie>
Oh, it actually uses a dfn: https://w3c.github.io/push-api/#dfn-permissiondeniederror

[07:34:41.0000] <Ms2ger>
You should kick whoever wrote that spec

[07:35:14.0000] <Ms2ger>
https://heycam.github.io/webidl/#dfn-error-names-table

[07:35:19.0000] <Ms2ger>
> If an error name is not listed here, please file a bug as indicated at the top of this specification and it will be addressed shortly. Thanks!

[07:35:51.0000] <Ms2ger>
NotAllowedError seems good enough, though

[09:39:55.0000] <wanderview>
annevk: the context of the meetup was angular2 which I guess offers observables or promises... you can either effectively

[09:43:05.0000] <wanderview>
would be nice to get cancelable fetch() though

[09:46:35.0000] <annevk>
Yeah, path to cancelable seems easier, but we'll find out soon enough

[09:51:11.0000] <jarek>
Why the spec allow something like "let option = new HTMLOptionElement()" but not "let button = new HTMLButtonElement()"?

[09:51:20.0000] <jarek>
Is this intentional or just work in progress?

[09:51:25.0000] <annevk>
yhirano_: I might not get to your XHR patch before Monday

[09:51:26.0000] <jarek>
s/allow/allows

[09:51:34.0000] <annevk>
yhirano_: sorry about that

[09:51:59.0000] <annevk>
jarek: which spec? I don't think either of those work

[09:52:25.0000] <annevk>
jarek: it only has new Option()

[09:52:33.0000] <jarek>
annevk: https://html.spec.whatwg.org/multipage/forms.html#the-option-element

[09:52:48.0000] <annevk>
jarek: note "Named" in "NamedConstructor"

[09:52:56.0000] <jarek>
annevk: they don't work in any browser afaik, but it should be easy to polyfill with proxies

[09:53:09.0000] <Domenic>
"easy" ... "proxies" .... O_o

[09:53:17.0000] <Ms2ger>
new HTMLOptionElement() does not work

[09:53:30.0000] <jarek>
annevk: I don't know WebIDL very well, what's the difference between NamedConstructor and Constructor?

[09:53:35.0000] <annevk>
jarek: if you can do that, would love to see it

[09:53:48.0000] <annevk>
jarek: note https://github.com/w3c/webcomponents/issues/369 for some difficulties with element constructors

[09:54:09.0000] <annevk>
jarek: NamedConstructor means the constructor name doesn't match the interface name

[09:54:46.0000] <annevk>
jarek: we also need to give each element a dedicated interface, or use arguments for local name, which gets ugly

[09:55:10.0000] <Domenic>
NamedConstructor basically creates a factory function that uses UA magic to construct the object

[09:55:14.0000] <Domenic>
It isn't a constructor at all

[09:55:38.0000] <jarek>
Domenic: window.HTMLButtonElement = new Proxy(window.HTMLButtonElement, {construct() { return document.createElement("button");}});

[09:56:01.0000] <Domenic>
jarek: sure, or just window.HTMLButtonElement = function () { return document.createElement("button"); }

[09:56:24.0000] <Domenic>
meh I guess that breaks the .prototype link, the proxy is kind of nice

[09:59:10.0000] <jarek>
Domenic: the spec says "When invoked as a constructor, it must return a new HTMLOptionElement object"

[10:00:17.0000] <jarek>
the terminology used by Web Components specs is really overwhelming to me

[10:02:10.0000] <jarek>
so NamedConstructor (unlike Constructor) is defined for the internal purposes? Is that correct?

[10:04:42.0000] <jarek>
ahh, I get it now, as per spec, you can do "let option = new Option()", but you can't do "let option = new HTMLOptionElement()"

[10:10:29.0000] <tobie>
Domenic: apologies for: "[URL] is obsoleted by [WHATWG-URL]." I know this needs fixing.

[10:18:51.0000] <smaug____>
annevk: I still don't understand why you're favoring the 3rd param approach of addEventListener

[10:19:10.0000] <smaug____>
that is against the basic rule we've been following elsewhere

[10:19:17.0000] <smaug____>
"spec what browsers do"

[10:19:20.0000] <Domenic>
tobie: yes, would be great :). But somehow that spec references both so presumably something is going wrong on that end too.

[10:20:03.0000] <annevk>
smaug____: how?

[10:20:42.0000] <annevk>
smaug____: but basically, the alternatives are worse

[10:20:47.0000] <smaug____>
how?

[10:21:53.0000] <annevk>
smaug____: keeps an awkward boolean argument that was already confusing and makes it mandatory

[10:22:27.0000] <smaug____>
/me notes that he was against making the boolean argument optional

[10:22:56.0000] <smaug____>
anyhow, the dictionary is for special cases only

[10:23:17.0000] <smaug____>
if you're going to use that, you sure should understand what different phases in dispatch mean

[10:23:22.0000] <annevk>
I don't think that would have worked with WebKit not requiring it, but that's also bad API

[10:23:59.0000] <annevk>
We might add more features going forward now it is easier to do so

[10:24:27.0000] <annevk>
This is a perfect way to enable more improvements without a whole redesign

[10:24:44.0000] <smaug____>
but this is totally not compatible with millions of browsers

[10:24:54.0000] <smaug____>
which won't be updated any time soon

[10:24:54.0000] <annevk>
It totally is

[10:25:15.0000] <annevk>
That is always a hazard with new features

[10:25:27.0000] <smaug____>
addEventListener is not a new feature

[10:27:40.0000] <smaug____>
/me so doesn't understand the argument that keeping 3rd param as boolean is that bad.

[10:28:04.0000] <smaug____>
since the arguments for that have been like "I just don't like it"

[10:33:58.0000] <annevk>
Overloading of the third arg is the new feature, does not break compat, so seems great

[10:34:58.0000] <smaug____>
it does break compat. passing { capturing: false} ends up being interpreted as true in older browsers

[10:35:11.0000] <smaug____>
s/capturing/capture/

[10:35:36.0000] <annevk>
Sure, so would most new features

[10:35:48.0000] <annevk>
That is why devs use libs

[10:36:02.0000] <annevk>
That feature test

[10:36:26.0000] <annevk>
And dismissing ergonomics like it is not a thing is unfair

[10:36:33.0000] <smaug____>
if the argument is now that devs use libs, then we can totally use 4th param approach, since that will be hidden anyway in the libs

[10:36:36.0000] <annevk>
API design matters

[10:37:03.0000] <annevk>
Hopefully not long term for all things

[10:49:09.0000] <annevk>
https://twitter.com/bitsgalore/status/709382042895654912 wow Steven Pemberton hasn't really changed his tune much if anything

[10:53:48.0000] <jgraham>
Mmm XForms + XSLT

[10:54:01.0000] <jgraham>
Nice punchline

[11:05:53.0000] <MikeSmith>
Steven is embarrassing himself with that stuff at this point

[11:06:07.0000] <MikeSmith>
it used to be kind of amusing but now it’s just sad

[11:46:51.0000] <MikeSmith>
TabAtkins: I think you may make better use of retweets than anybody else I know

[11:47:18.0000] <MikeSmith>
case in point your retweet about http://gutenberg-poetry.decontextualize.com/

[11:55:30.0000] <Mek>
MikeSmith: I'm the volunteer/victim jsbell found to edit FileAPI... could you give me ('mkruisselbrink') the appropriate powers to be able to do so?

[11:55:50.0000] <jsbell>
\o/

[12:01:06.0000] <MikeSmith>
w00t

[12:01:12.0000] <MikeSmith>
howdy Mek

[12:01:16.0000] <MikeSmith>
jsbell++

[12:01:30.0000] <MikeSmith>
y’all rock the bells

[12:01:36.0000] <MikeSmith>
Mek: yup will do right now

[12:02:32.0000] <MikeSmith>
done

[12:02:44.0000] <Mek>
MikeSmith: awesome, thanks

[12:03:09.0000] <MikeSmith>
Mek: very glad this landed on your plate

[12:03:35.0000] <MikeSmith>
I “know” you from seeing your comments/contributions to other repos

[12:41:09.0000] <aklein>
Domenic: do you happen to know anything about <script> in SVG?

[12:41:49.0000] <aklein>
Domenic: Blink's implementation of script handling doesn't do a lot to distinguish between the processing model of HTML and SVG scripts, wondering how hard it would be to spec type=module for SVGScriptElement

[12:44:21.0000] <aklein>
hmm, the current spec just seems to have placeholders for some of the "new" HTML features anyway

[12:44:21.0000] <aklein>
https://www.w3.org/TR/SVG2/interact.html#ScriptElement

[12:54:40.0000] <Domenic>
aklein: yeah I don't know much... I remember an open bug or two

[12:55:14.0000] <Domenic>
Can we just make SVG2 use HTMLScriptElement? TabAtkins heycam|away

[12:56:16.0000] <pdr>
Domenic, I don't think we can for namespace reasons

[12:56:34.0000] <TabAtkins>
Domenic: I'm 100% for it, same with <style>.  SVGWG is for it, as long as browsers are okay with compat.  Objection is what pdr said.

[12:56:53.0000] <pdr>
But the spec says ""A ‘script’ element is equivalent to the ‘script’ element in HTML and thus is the place for scripts"" which seems to me to mean that the two are equivalent and module should work for svg too

[12:57:37.0000] <Domenic>
pdr: I thought the plan was for SVG2 to merge the namespaces or something

[12:58:11.0000] <Domenic>
pdr: does it also say that SVGScriptElement is "equivalent" to HTMLScriptElement?

[12:58:51.0000] <TabAtkins>
tobie: Headings can define things, too.  <h3 algorithm abstract-op>Update State</h3> works.

[12:59:00.0000] <Domenic>
I guess not

[12:59:32.0000] <TabAtkins>
tobie: The markdown rules, generally, are that when you open a container element the contents have to be indented one more level.

[12:59:34.0000] <Domenic>
TabAtkins: doesn't svg have a version parameter that could help with any compat issues?

[12:59:38.0000] <tobie>
TabAtkins: yeah, I assumed dfn was a tag and thus…

[12:59:39.0000] <TabAtkins>
Domenic: No.

[12:59:55.0000] <TabAtkins>
tobie: I don't understand what you mean.

[13:00:03.0000] <TabAtkins>
Oh! "dfn" type definitions.

[13:00:04.0000] <Domenic>
TabAtkins: <svg xmlns="http://www.w3.org/2000/svg" version="1.1">

[13:00:19.0000] <TabAtkins>
Yeah, sorry about that being confusing. Mistake on my part early on in naming, can't be fixed now.

[13:00:26.0000] <TabAtkins>
Domenic: That has no effect on anything.

[13:00:36.0000] <Domenic>
I guess you're saying browsers don't want to implement a version switch, which is fair

[13:00:39.0000] <TabAtkins>
Yeah.

[13:01:10.0000] <tobie>
TabAtkins: gotcha, np. As most things, obvious once you're aware of it, arcane before then.

[13:01:52.0000] <Domenic>
This is the bug I remember BTW https://www.w3.org/Bugs/Public/show_bug.cgi?id=28753

[13:03:19.0000] <TabAtkins>
Domenic: The *intention* is definitely that <svg:style> and <svg:script> be exactly identical to the HTML versions in every way.  Whatever needs to be fixed to make that happen, we're happy to do.

[13:03:49.0000] <TabAtkins>
If we could make it automatic by merging them, that would be great, but some implementors have an aversion to "chameleon" elements that are identical in multiple namespaces. :/

[13:04:04.0000] <Domenic>
TabAtkins: well saying that the element interface for ("http://www.w3.org/2000/svg", "script") is HTMLSVGElement sounds like the right fix to me

[13:04:14.0000] <Domenic>
Darn implementers.

[13:04:21.0000] <Domenic>
*HTMLScriptElement

[13:09:33.0000] <TabAtkins>
Works for me. Poke at pdr and whoever's doing it in Firefox. ^_^

[14:11:52.0000] <zcorpan>
TabAtkins: when should abstract-op be used?

[14:12:14.0000] <TabAtkins>
when you're defining an abstract operation. Use your best judgement.

[14:13:01.0000] <TabAtkins>
(I'm gonna add a metacategory for autolinking to dfn/abstract-op/any other English-language definition categories I add in the future, like <a idl> is for all IDL types, so it's easy to link.)

[14:13:38.0000] <TabAtkins>
Gotta do some more refactoring of the autolinker first to make that possible tho, because "abstract-op" doesn't automatically lowercase the definition, like "dfn" does.

[14:14:48.0000] <zcorpan>
i'm not familiar with the terminology "abstract operation" to be able to apply judgement. any example or pointer?

[14:17:12.0000] <TabAtkins>
Any time you're defining something that you'll call like a method, but it's just normal language.

[14:17:26.0000] <zcorpan>
ok

[14:18:01.0000] <TabAtkins>
Like https://dom.spec.whatwg.org/#get-the-parent

[14:18:22.0000] <zcorpan>
and so what does bikeshed do differently from "dfn"?

[14:18:40.0000] <TabAtkins>
It doesn't assume that it can lowercase it freely.

[14:19:31.0000] <TabAtkins>
https://github.com/tabatkins/bikeshed/issues/625 is where it was added, with examples asking for it.


2016-03-18
[17:59:53.0000] <annevk>
Domenic: maybe HTML should simply  define svg:image and svg:script directly, if they are to be largely, but not quite, identical

[19:27:42.0000] <TabAtkins>
annevk: Yeah, that would be nice if we end up not being able to unify, just because they're so complex. Being defined together would reduce the chance of them accidentally diverging.

[21:48:33.0000] <pikaren>
should i use "no-referrer" or "none" or "never" in the meta referrer tag?

[21:49:00.0000] <pikaren>
which one is recognized most mainstream browsers

[21:49:05.0000] <pikaren>
by most

[00:33:50.0000] <annevk>
pikaren: "never" I suspect

[00:34:04.0000] <pikaren>
oh

[00:34:26.0000] <annevk>
pikaren: see https://wiki.whatwg.org/wiki/Meta_referrer for the original spec

[00:34:32.0000] <annevk>
"spec"

[00:34:36.0000] <pikaren>
i saw some stackoverflow folks suggest using no-referrer though

[00:35:34.0000] <pikaren>
do all the newer browsers try to support "never"

[00:36:21.0000] <annevk>
pikaren: yeah, that's required by https://w3c.github.io/webappsec-referrer-policy/#determine-policy-for-token

[00:38:22.0000] <pikaren>
oh

[00:38:26.0000] <pikaren>
nice

[00:38:28.0000] <pikaren>
thanks

[03:38:47.0000] <derekjohnson>
Hi, I have a couple of questions about sectioning root. Is this the right place to ask?

[04:04:31.0000] <tobie>
Are there examples of interfaces holding onto promises similar to ServiceWorkerContainer.ready, but that can cycle through the states multiple time during the object's lifetime (sensor state can go multiple time through the cycle idle -> activating -> active and needs a promise that gets resolved when active).

[04:36:25.0000] <tobie>
annevk: you mentioned cancellable promises yesterday. What's my best move right now? Return a promise, throw an Abort error on cancellation and retrofit later to cancellable promises or, instead, remove promise for now (they're not critical as there are also statechange events being dispatched) and add them back in once cancellables are a thing?

[04:46:35.0000] <annevk>
tobie: not sure, ask JakeA / Domenic

[04:46:59.0000] <annevk>
derekjohnson: yeah, I guess it is, though not sure if there's folks around who can help right now

[04:52:02.0000] <derekjohnson>
annevk: I'll give it a shot anyway :) First question is why is sectioning root deemed necessary? Second is what is different about the elements that are sectioning root (apart from body) that makes them worthy of having their contents hidden from the main outline?

[04:57:34.0000] <annevk>
derekjohnson: I think the idea is that if you quote a substantial piece of an article, the headings of that article shouldn't be part of your outline, since they're just part of a quote

[05:04:49.0000] <derekjohnson>
annevk: kind of weird that if someone uses <figure> for products on an ecommerce site or <details> for a subnav or something that they get treated like a portion of a quoted article.

[05:06:24.0000] <annevk>
derekjohnson: well, I think similar considerations apply there

[05:07:05.0000] <annevk>
derekjohnson: you typically don't have "Graph 50: Population growth" in your main outline

[05:08:06.0000] <derekjohnson>
annevk: agree, but you do have "Bow saw", "Hacksaw", "Chainsaw" in a list of products

[05:08:36.0000] <annevk>
derekjohnson: a list of products isn't really <details> though, is it?

[05:08:37.0000] <derekjohnson>
annevk: I should say I use <article> for product lists but I've seen <figure> used a lot

[05:09:23.0000] <annevk>
derekjohnson: seems spurious, but since outline is so poorly supported, it's no surprise

[05:10:01.0000] <derekjohnson>
annevk: yeah we're talking about something that doesn't really exist, it interests me though

[05:10:57.0000] <annevk>
I need to figure out if it will ever get implemented, if it doesn't, we might have to remove it from the specification 😟

[05:28:45.0000] <beverloo>
MikeSmith, hi!

[05:29:33.0000] <beverloo>
MikeSmith, could I be added as a contributor on the push-api w3c repo?

[06:11:01.0000] <annevk>
smaug____: if https://github.com/WICG/EventListenerOptions/issues/11#issuecomment-198348071 is actually easy, feel free to demonstrate

[06:11:10.0000] <annevk>
smaug____: I have many doubts

[06:11:38.0000] <smaug____>
what kind of doubts?

[06:11:53.0000] <annevk>
smaug____: that it would be easy

[06:12:27.0000] <smaug____>
what part do you consider hard there?

[06:12:50.0000] <annevk>
I also don't like that it encourages a different this binding from all other callbacks and calls the callback member "handleEvent"

[06:13:18.0000] <annevk>
smaug____: afaict you'd have to do what philipj says and write out the whole binding yourself

[06:13:33.0000] <annevk>
smaug____: again, if you see an easy alternative, please demonstrate, no need to discuss if it's easy

[06:14:38.0000] <smaug____>
so what is wrong with the approach that there is dictionary EventListenerOpts { boolean passive = false;};

[06:14:56.0000] <smaug____>
then eventlistener param is changed to object or any

[06:15:25.0000] <smaug____>
first you do listener -> dictionary conversion and read the passive value

[06:15:31.0000] <annevk>
I don't understand what object or any means, how is that not any?

[06:15:34.0000] <smaug____>
and then you do whatever is happening now

[06:16:07.0000] <smaug____>
the type of the listener would be object (or any, not sure which one would be better)

[06:16:36.0000] <annevk>
IDL handles dictionary conversion, I'm not sure how you'd do that in prose

[06:16:54.0000] <annevk>
Apart from just copying and pasting those algorithms, perhaps creating abstractions, etc.

[06:17:01.0000] <annevk>
Definitely not easy

[06:17:15.0000] <smaug____>
we have dictionary conversion in prose elsewhere

[06:17:20.0000] <smaug____>
in specs

[06:17:24.0000] <annevk>
No we don't

[06:17:29.0000] <smaug____>
https://html.spec.whatwg.org/multipage/scripting.html#coerce-context-arguments-for-2d for example

[06:17:52.0000] <annevk>
That's not a dictionary

[06:18:03.0000] <smaug____>
https://html.spec.whatwg.org/multipage/scripting.html#canvasrenderingcontext2dsettings is dictionary

[06:19:03.0000] <annevk>
ew

[06:19:12.0000] <smaug____>
RenderingContext? getContext(DOMString contextId, any... arguments); and the first any argument is converted to dictionary conditionally

[06:19:18.0000] <smaug____>
based on the contextID

[06:19:39.0000] <smaug____>
so we totally do that conversion in prose

[06:20:00.0000] <annevk>
I guess we do

[06:21:13.0000] <annevk>
Note that this also means we have to keep more objects alive for each listener

[06:21:58.0000] <smaug____>
we do?

[06:21:59.0000] <annevk>
It doesn't seem like a great alternative to me

[06:22:11.0000] <smaug____>
I don't see any need for more objects

[06:22:29.0000] <annevk>
smaug____: yeah, because folks will be encouraged to pass in objects that reference a callback, and we can't throw away that object as we can with dictionaries since it's the this value

[06:22:56.0000] <smaug____>
oh you mean that. not worried about that at all

[06:23:20.0000] <smaug____>
I don't even see why to worry about that

[06:24:21.0000] <annevk>
It's also less compatible since if that object already has members we might be changing the semantics of deployed valid code

[06:24:47.0000] <annevk>
That is, this approach isn't even backwards compatible

[06:26:54.0000] <smaug____>
that is a risk. but I consider the risk less than what 3rd param approach has

[06:27:30.0000] <smaug____>
we could reduce the risk by changing the name for passive to something less common

[06:30:04.0000] <annevk>
The 3rd param approach has no risk for valid existing code

[06:30:55.0000] <annevk>
I don't think 1-2 year browser upgrade cycle is an actual risk worth caring about. These APIs are with us for the long term.

[06:31:10.0000] <annevk>
Once we start caring about forward compat we might as well stop

[06:31:35.0000] <annevk>
As philipj suggested elsewhere we should probably make feature detection easier for dictionaries somehow

[06:31:44.0000] <annevk>
That's something worth looking into

[06:40:03.0000] <smaug____>
3rd param causes the risk for pages being broken for many users.

[06:41:27.0000] <annevk>
Maybe the risk is a little higher than with a new API, but it's really not that different

[06:42:28.0000] <annevk>
And at least it doesn't break old content forever

[06:42:53.0000] <annevk>
Which I think is much worse, since that is far less likely to be fixed

[07:51:02.0000] <JonathanNeal>
normalize.css v4 is being prepared tonight. if anyone has a minute to look for anything that might have snuck past us on master or in the last pull requests, it helps prevent bugs from making it into 4.0.0. https://twitter.com/jon_neal/status/710840040394530816

[10:02:57.0000] <MikeSmith>
beverloo: hi, setting you up now

[10:04:27.0000] <MikeSmith>
and done

[10:05:48.0000] <beverloo>
thank you!

[10:09:24.0000] <annevk>
wanderview: is https://github.com/whatwg/fetch/issues/245 high priority?

[10:09:39.0000] <annevk>
wanderview: mostly working on Shadow DOM at the moment

[10:10:15.0000] <wanderview>
annevk: don't think its a top priority no... was just referencing another instance I saw

[10:10:23.0000] <wanderview>
annevk: maybe we can discuss at the f2f

[10:10:42.0000] <annevk>
wanderview: thanks, yeah, would be curious to hear what others think

[10:10:42.0000] <wanderview>
I mean... the people who go to the f2f

[10:11:08.0000] <annevk>
wanderview: I'd be happy to silently fail and make sure new Request(url, someotherrequest) always works

[10:11:34.0000] <annevk>
wanderview: while resetting certain state as appropriate, of course

[10:11:40.0000] <wanderview>
annevk: some kind of "safe url rewrite" function might be more convenient for what people really want, though

[10:12:06.0000] <annevk>
wanderview: well that's called a redirect

[10:14:18.0000] <wanderview>
annevk: I guess evt.respondWith(evt.request.redirect(newURL)) will result in the service worker getting entered again, right?

[10:14:21.0000] <wanderview>
I believe it will

[10:19:58.0000] <annevk>
yup

[10:22:09.0000] <wanderview>
and that chromium issue was trying to avoid a bug in chrome, so it wasn't rewriting the url anyway

[15:37:21.0000] <TabAtkins>
Domenic, annevk: Anything wrong conceptually with letting <video>/<audio>/<picture> inside of <svg> parse as the <html:*> elements?  That is, set up the right (HTML) namespace on them?

[15:37:43.0000] <TabAtkins>
Obvi not possible for the SVG-as-XML syntax, but for the embedded-SVG syntax?

[15:41:05.0000] <Domenic>
TabAtkins: seems quite reasonable to me.

[15:46:19.0000] <jsbell>
annevk: any plans to bikeshed Encoding?

[15:47:35.0000] <jsbell>
Also, has anyone plotted "# spec authoring tools" vs "# spec editors" over time?

[15:48:20.0000] <TabAtkins>
# of authoring tools has remained approximately flat for a while.  Bikeshed rose from the corpse of the "Bert's preprocessor", so a net 0 gain.

[15:48:52.0000] <TabAtkins>
(Or rather, it quickly cannibalized all uses of Bert's preprocessor as its first victim.)


2016-03-19
[00:28:33.0000] <annevk>
TabAtkins: HTML elements in SVG could work, someone would have to figure out parsing rules

[09:01:30.0000] <gabr13l>
o/

[12:27:46.0000] <JonathanNeal>
Hello


2016-03-20
[22:10:31.0000] <TrustInAllah>
I will post a video of a series of lectures on the Hereafter on what happens to us after this life, I know you're all busy with your works and this might be irrelevant to your interests but this is  extremely important. Please pause whatever is you're doing and put it on hold as death is a reality which none of us can escape, https://www.youtube.com/watch?v=J6POzsLaKP4&list=PLyIDfFGMrsvtUiDND

[22:10:32.0000] <TrustInAllah>
0bzdKagGyejGWYJU

[04:31:32.0000] <tobie>
Kind of confused as to what the right language is to fire error events.

[04:32:47.0000] <tobie>
Say I have a NotAllowedError DOMException, how do I turn that into an event and dispatch it?

[04:34:57.0000] <tobie>
Do I need to use the ErrorEvent interface and set each of its attributes to the corresponding ones in my DOMException object?

[04:35:53.0000] <tobie>
Or do I just only need to "fire a simple event named error"?

[04:40:43.0000] <annevk>
tobie: depends on what you want 😊

[04:41:02.0000] <annevk>
tobie: latter is more typical I'd say

[04:41:04.0000] <tobie>
annevk: well, consistency with the rest of the platform

[04:41:45.0000] <tobie>
annevk: but the API consumer needs to be able to know why the event was fired

[04:42:46.0000] <tobie>
annevk: e.g. was permission denied or does the sensor not accept frequency above 250 Hz, for example

[04:44:07.0000] <tobie>
annevk: does "fire a simple event named error" actually allow any of that?

[04:46:17.0000] <annevk>
tobie: not really

[04:47:28.0000] <tobie>
annevk: OK, so I guess I'm not doing this the right way, then.

[04:52:03.0000] <tobie>
annevk: should I use an error attribute on the sensor object?

[04:52:10.0000] <tobie>
That seems really ugly.

[04:57:33.0000] <annevk>
tobie: you could define your own event class

[04:58:33.0000] <tobie>
annevk: oh, you mean like a DomExceptionEvent that takes a DOMException as argument and does all the things it needs to?

[04:59:15.0000] <tobie>
Wouldn't that belong at a lower layer of the platform, though? like in DOM?

[05:00:34.0000] <annevk>
tobie: hmm, depends on the requirements

[05:03:57.0000] <tobie>
annevk: well I guess the only requirement on my part would be for the API consumer to get the error through the error attribute of the event.

[05:05:13.0000] <tobie>
annevk: I'aware there are security issues about passing errors around, but I'm not well versed enough in the issue to see whether this would be a problem here.

[05:05:28.0000] <tobie>
*I'm

[05:06:41.0000] <tobie>
annevk: tbh, I'm kind of surprised you can't systematically reach an error object from an error event.

[05:26:53.0000] <annevk>
tobie: sorry, back tomorrow

[05:27:00.0000] <tobie>
np

[05:27:16.0000] <tobie>
annevk: it's Sunday, after all!

[09:57:17.0000] <annevk>
tobie: so mostly, I think that most APIs don't have the need for both exceptions and events modeling those exceptions

[09:57:34.0000] <annevk>
tobie: I think that if you have a need for that, you should just introduce something

[09:58:56.0000] <tobie>
annevk: I wrote it up like that: https://w3c.github.io/sensors/#handle-errors


2016-03-21
[04:04:59.0000] <mohsen_>
Can whatwg provide off site notification support?

[04:07:38.0000] <annevk>
mohsen_: not sure what that means

[04:09:57.0000] <mohsen_>
Receiving notification when the browser is closed

[04:16:33.0000] <annevk>
mohsen_: the unload event provides that

[04:17:12.0000] <mohsen_>
 Do you have an example for that?

[04:55:55.0000] <annevk>
mohsen_: window.onunload = ...

[05:00:10.0000] <mohsen_>
annevk: No I mean after that, when the browser is closed, the user still receive notifications from server.

[05:02:19.0000] <annevk>
mohsen_: oh, https://w3c.github.io/push-api/

[05:36:34.0000] <annevk>
Anyone know how to suppress a bikeshed IDL LINK ERROR?

[05:38:27.0000] <annevk>
I'll ignore it for now

[06:20:52.0000] <smaug____>
oh, ShadowRoot is in dom spec now

[06:20:56.0000] <smaug____>
good good

[06:21:42.0000] <annevk>
It's quite a bit of work, but slowly getting there

[06:23:54.0000] <tobie>
mounir: wouldn't it make sens to have an abstract operation in Permissions-API to request permission if the request permission state returns "prompt"? I'm seeing everyone come up with roughly the same boilerplate for this.

[07:19:44.0000] <mounir>
tobie: wdym?

[07:34:59.0000] <tobie>
mounir:  retrieving the permission state, returns one of "granted", "denied" or "prompt"

[07:35:32.0000] <tobie>
mounir: "granted" let's you go ahead with whatever it was you wanted to do.

[07:35:47.0000] <mounir>
tobie: sounds reasonable

[07:36:43.0000] <tobie>
mounir: "denied" pretty much forces you to throw/reject with a NotAllowedError

[07:37:09.0000] <mounir>
I would leave that to the implementation

[07:37:32.0000] <tobie>
mounir: arguably

[07:37:57.0000] <mounir>
I guess we could have two algorithms: one basic that checks the permission and return the result

[07:38:05.0000] <tobie>
mounir: and "prompt" pretty much asks you to do a little dance prompting the user (or some such)

[07:38:10.0000] <mounir>
one that "do X if allowed" and rejects otherwise

[07:38:32.0000] <mounir>
some specs wouldn't

[07:38:47.0000] <mounir>
background-sync so far is a UA permission for example

[07:38:51.0000] <mounir>
as in not in the user's face

[07:39:25.0000] <tilal6991>
Curious as to what is being discussed? :)

[07:40:06.0000] <tobie>
mounir: I'm not suggesting *all* specs should do the same, but a lot do something similar, eg midi: http://webaudio.github.io/web-midi-api/#dfn-algorithm-to-request-midi-access

[07:42:04.0000] <tobie>
tilal6991: a common abstract operation to ask for use permission in case the return value of the  request permission state abstract operation is "prompt".

[07:42:39.0000] <mounir>
tobie: interested in writing it? :)

[07:43:14.0000] <tilal6991>
tobie: I see. If you do write it ^ have fun :P

[07:43:47.0000] <tobie>
mounir: well, I have to write it for the sensor API, so I might as well write it for the permissions API. :)

[07:44:06.0000] <mounir>
I take PR :)

[07:45:05.0000] <tilal6991>
mounir and I did a lot of that work on the permissions code last summer. Haven't looked at it for a while though so not sure what state it's in

[07:48:57.0000] <mounir>
tilal6991: I tihnk tobie is mostly interested about the spec :)

[07:50:05.0000] <tilal6991>
Oh I misunderstood. Still figuring out the interaction with requests would be interesting.

[07:50:31.0000] <tobie>
tilal6991, mounir: well, spec, sure; but I also want to make sure it can be easily implemented as one of the Intel guys working on this is about to send an intent to implement

[07:51:25.0000] <mounir>
tobie: in Chromium, it should be fine

[07:52:01.0000] <tobie>
mounir: awesome

[07:52:26.0000] <tobie>
tilal6991: can Riju ping you if he has issues/questions around this?

[07:52:29.0000] <smaug____>
annevk: have we considered exposing shadom dom only in secure contexts ?

[07:52:37.0000] <smaug____>
shadow dom and custom elments

[07:52:41.0000] <smaug____>
elements

[07:52:47.0000] <annevk>
smaug____: I don't think we have

[07:53:25.0000] <annevk>
smaug____: I would be okay with that, file an issue against w3c/webcomponents?

[07:53:26.0000] <smaug____>
/me files a bug. Something to consider at least

[07:53:44.0000] <tilal6991>
Well sure but I've been out of chromium for a little while now. mounir would be the better person to ask since he owns the code but I can chip in sure

[07:54:22.0000] <mounir>
tobie: Riju should feel free to ping me

[07:54:23.0000] <tobie>
tilal6991: noted. thanks

[07:54:33.0000] <tobie>
mounir: noted.

[07:54:51.0000] <tobie>
mounir: where's "permission" precisely defined, btw?

[07:55:33.0000] <mounir>
tobie: hmm, that sounds like a tricky question :)

[07:55:58.0000] <tobie>
mounir: tricky or trick?

[07:56:17.0000] <mounir>
trick, sorry

[07:57:58.0000] <tobie>
mounir: well, maybe, I'm not sure. I can't find a dfn for it, and I'm unsure if it means the PermissionName, a PermissionDescriptor with name set to xxx, etc.

[07:58:49.0000] <tobie>
mounir: I refer to it like so in the Sensor spec: https://w3c.github.io/sensors/#retrieve-the-sensor-permission

[08:11:55.0000] <zcorpan>
why isn't <option> in the list of "Special" elements (in the parser)?

[08:14:09.0000] <annevk>
zcorpan: not sure, there's a couple of special category conditionals, are those affected?

[08:14:19.0000] <annevk>
/me is trying to figure out how to define <slot> parsing

[08:23:11.0000] <annevk>
gsnedders: so... html5lib doesn't support <template>?

[08:34:16.0000] <gsnedders>
annevk: no, it doesn't

[08:45:04.0000] <zcorpan>
annevk: hmm right, in particular "any other end tag". probably menuitem shouldn't be special but i'm not entirely sure yet

[08:46:14.0000] <zcorpan>
also AAA

[08:47:00.0000] <annevk>
zcorpan: if those are actually what makes option not special, that is worthy of a note

[08:47:05.0000] <annevk>
zcorpan: seems super confusing

[08:47:14.0000] <annevk>
zcorpan: file an issue, assign to Hixie_?

[08:55:11.0000] <zcorpan>
doneth

[08:55:53.0000] <annevk>
ta

[09:24:27.0000] <tobie>
jyasskin: hey--it seems you've written the core of the "request permission" abstract operation I also need in a branch of your fork of the Permissions API.

[09:24:53.0000] <tobie>
jyasskin: mounir and I were just discussing this above.

[09:25:14.0000] <jyasskin>
I'm on vacation today, so can't reply much.

[09:25:36.0000] <tobie>
jyasskin: oh--sorry.

[09:25:47.0000] <tobie>
jyasskin: when are you back?

[09:25:49.0000] <jyasskin>
But I'll scroll up and read your conversation tomorrow. Feel free to send comments on the PR, or take it over and merge it. :)

[09:26:15.0000] <tobie>
oh, I must have somehow missed the PR.

[09:27:52.0000] <tobie>
jyasskin: looking

[09:30:52.0000] <jyasskin>
https://github.com/w3c/permissions/pull/66

[09:35:45.0000] <tobie>
jyasskin: ty

[09:36:16.0000] <tobie>
jyasskin: you'll be interested in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27048 for adding support for partial enums in WebIDL

[09:43:52.0000] <tobie>
Would be easier if WebIDL consolidated its issue trackers.

[09:46:30.0000] <Ms2ger>
Would be easier if it had an active editor

[09:46:35.0000] <tobie>
mounir: what I'm looking for is basically in: https://github.com/w3c/permissions/pull/66

[10:13:08.0000] <smaug____>
is [Unscopeable] actually used in any spec?

[10:13:27.0000] <annevk>
smaug____: it's in DOM

[10:14:33.0000] <smaug____>
ah, there

[10:14:36.0000] <smaug____>
not in HTML

[10:19:37.0000] <smaug____>
hmm, different thing

[10:19:59.0000] <smaug____>
https://dom.spec.whatwg.org/#dom-childnode-before am I reading that right, or does the algorithm actually end up putting nodes before previous sibling

[10:20:08.0000] <smaug____>
s/right/wrong/

[10:21:13.0000] <smaug____>
"Pre-insert node into parent before viablePreviousSibling. "

[10:22:36.0000] <smaug____>
oh, no, there is 5

[10:22:38.0000] <smaug____>
nm

[10:23:08.0000] <smaug____>
odd reuse of viablePreviousSibling variable

[10:24:10.0000] <annevk>
smaug____: if it's confusing, I take PRs or issues

[12:06:49.0000] <rniwa>
annevk: yt?

[14:07:03.0000] <jyasskin>
annevk: Getting rid of Link Errors in bikeshed generally involves adding an item to the 'anchors' or 'link-defaults' blocks at the top of your spec. See https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/index.bs for a bunch of examples.

[14:09:43.0000] <jyasskin>
tobie: Yeah, I've seen that bug. I was waiting to push on it until I'd fixed the Permissions spec to handle other specs extending it.

[14:11:27.0000] <jyasskin>
To really fix it, it'd be nice to have a catalog of the "registries" in HTML specs, to see if they could all be handled in some uniform way other than partial enums. But failing that, partial enums look like they're probably enough for Permissions.

[14:16:26.0000] <tobie>
Yeah. Baby steps. Also, weren't you supposed to be on PTO? ;)


2016-03-22
[01:23:59.0000] <annevk>
rn... am now

[01:40:32.0000] <tobie>
JakeA: would love your input on whether or not to wait for cancellable promises for returning a promise from the start method of sensors.

[01:45:10.0000] <tobie>
or Domenic

[01:45:46.0000] <JakeA>
tobie: I'm worried about ending up with legacy APIs that use rejection to mean cancellation

[01:47:51.0000] <tobie>
JakeA: right, so I have a start/stop pair. start returned a promise that stop could abort before the sensor was fully activated.

[01:48:26.0000] <tobie>
JakeA: so yeah, rejected the promise.

[01:49:52.0000] <tobie>
JakeA: given there are statechange events, the promise isn't strictly necessary (it's sugar really), it *can* wait until a v2 of the spec.

[01:50:03.0000] <tobie>
JakeA: should it?

[01:50:51.0000] <tobie>
JakeA: seems your answer is "yes" and that's what I've gone with so far, but I want to make sure, so I have a good answer for all the people that are going to complain for the lack of promise in that API.

[01:50:56.0000] <tobie>
:)

[01:52:04.0000] <JakeA>
tobie: yeah, I think so, but will let Domenic have the final word

[01:52:55.0000] <tobie>
JakeA: for reference: https://w3c.github.io/sensors/#sensorstart

[01:52:57.0000] <JakeA>
The alternative is to add the promise, but when it's cancelled just never resolve the promise. That lets you add cancellation later. But it's a bit eww

[01:53:40.0000] <tobie>
JakeA: yeah--that sounds like even more explaining to do.

[01:56:48.0000] <tobie>
JakeA: Thanks for the help.

[02:15:19.0000] <zcorpan>
how do i run the html5lib tests with html5lib-python? jgraham gsnedders

[02:15:37.0000] <zcorpan>
i want to write new tests for <menuitem> parsing

[02:19:07.0000] <jgraham>
zcorpan: They are in wpt. There is a script to generate new tests from html5lib source files in html/tools iirc

[02:20:11.0000] <Ms2ger>
Presumably that's not the optimal way to test html5lib-python though

[02:23:28.0000] <zcorpan>
jgraham: yes, i found that but i figured if i want to write new tests it makes more sense to run the tests with html5lib than to run them in a browser?

[02:24:10.0000] <zcorpan>
jgraham: it's not clear to me what the typical procedure is for writing a new test, and it's not clear to me how to run tests with html5lib-python from reading the READMEs

[02:24:38.0000] <zcorpan>
(i have no idea what tox is)

[02:30:02.0000] <jgraham>
Oh I read "with" as "without"

[02:30:09.0000] <jgraham>
Makes a difference

[02:30:32.0000] <zcorpan>
heh

[02:31:50.0000] <jgraham>
zcorpan: tests/README sort of tells you

[02:32:01.0000] <jgraham>
Install nose

[02:32:06.0000] <jgraham>
and type

[02:32:09.0000] <jgraham>
nose

[02:32:11.0000] <jgraham>
or

[02:32:16.0000] <jgraham>
node path/to/test.py

[02:33:31.0000] <jgraham>
s/nose/nosetests/

[02:33:41.0000] <jgraham>
and also not node

[02:33:51.0000] <zcorpan>
pip install nosetests ?

[02:33:52.0000] <jgraham>
such an unfortunate typo

[02:33:56.0000] <jgraham>
Yeah

[02:34:05.0000] <jgraham>
Well I think pip install nose

[02:34:19.0000] <jgraham>
The package is nose but the command is nosetests

[02:35:26.0000] <jgraham>
(Seems like pytest also works if that's less confusing)

[02:35:47.0000] <jgraham>
(but maybe doesn't respect the skip annotations or something)

[02:37:32.0000] <zcorpan>
Cleaning up...

[02:37:33.0000] <zcorpan>
Exception:

[02:37:33.0000] <zcorpan>
Traceback (most recent call last):

[02:37:34.0000] <zcorpan>
  File "/Library/Python/2.7/site-packages/pip-1.5.6-py2.7.egg/pip/basecommand.py", line 122, in main

[02:37:36.0000] <zcorpan>
    status = self.run(options, args)

[02:39:40.0000] <zcorpan>
installing pytest worked

[02:43:07.0000] <zcorpan>
py.test runs now. lots of tests and quite a bit of "F"s :-)

[02:44:41.0000] <zcorpan>
676 failed, 25007 passed, 118 skipped, 2 pytest-warnings, 1 error in 168.03 seconds

[02:48:30.0000] <zcorpan>
though py.test tree_construction.py runs 0 tests. renaming the file to test_tree_construction.py gives: WC1 /Users/zcorpan/VCS/git/html5lib/html5lib-python/html5lib/tests/test_tree_construction.py cannot collect test class 'TestData' because it has a __init__ constructor

[02:51:23.0000] <zcorpan>
ok installed nose with easy_install instead

[02:54:44.0000] <zcorpan>
how do i run only the treebuilder tests?

[03:06:35.0000] <zcorpan>
nosetests test_treewalkers.py

[03:07:18.0000] <zcorpan>
jgraham: can i restrict it more to only run a specific dat file? haven't figured it out by myself yet from nosetests --help

[03:09:25.0000] <jgraham>
zcorpan: test_treewalkers isn't what you want, it's test_parser

[03:10:15.0000] <zcorpan>
jgraham: test_parser2.py ?

[03:11:16.0000] <jgraham>
I don't actually know what the reason for test_parser and test_parser2 is

[03:11:33.0000] <zcorpan>
i don't see any test_parser

[03:11:54.0000] <jgraham>
Looks like there isn't an easy way to run a specific .dat file, but you could hack get_data_files in support.py

[03:12:11.0000] <jgraham>
Oh?

[03:12:22.0000] <jgraham>
Looking at test_parser2 it clearly isn't what you want

[03:13:20.0000] <zcorpan>
https://github.com/html5lib/html5lib-python/tree/master/html5lib/tests no test_parser.py here

[03:13:32.0000] <jgraham>
Oh wait, it looks like I had an old checkout and gsnedders changed something

[03:14:54.0000] <jgraham>
I guess these days you are supposed to use py.test and tree_construction.py

[03:16:23.0000] <zcorpan>
https://github.com/html5lib/html5lib-python/commit/9337b003fa4465e91c1d9b3271064e34e26d876b ?

[03:17:46.0000] <zcorpan>
gsnedders: help?

[03:23:38.0000] <zcorpan>
py.test testdata/tree-construction/main-element.dat seems to work?

[03:29:24.0000] <jgraham>
Neat

[03:30:22.0000] <zcorpan>
ok now i'm happy (for now). might need help again with the wpt import later :-)

[03:30:27.0000] <zcorpan>
thx!

[03:39:39.0000] <zcorpan>
hsivonen: i get 502 for https://validator.nu/ and https://html5.validator.nu/

[03:43:23.0000] <annevk>
zcorpan: I'm running into https://www.w3.org/Bugs/Public/show_bug.cgi?id=25552 and co with <slot>

[03:44:11.0000] <annevk>
zcorpan: <slot> needs to be as generic as <template> more or less

[03:44:44.0000] <zcorpan>
annevk: any opinions? i still think script and template should be allowed in as many places as possible, basically

[03:45:13.0000] <annevk>
zcorpan: I tend to agree, the parser already allows for it and implementations already deal, right?

[03:46:14.0000] <annevk>
zcorpan: I'll also need your help with <slot> since I don't really have a firm grasp on how all the details need to be filled in

[03:46:26.0000] <zcorpan>
annevk: right. iirc there's like one exception where the parser supports script but not template for some reason

[03:47:32.0000] <zcorpan>
annevk: i still need to fix the <template> content model bug

[03:47:57.0000] <zcorpan>
annevk: does <slot> parse into a different tree like <template> does?

[03:49:43.0000] <annevk>
zcorpan: no

[03:49:48.0000] <annevk>
zcorpan: that's the main difference

[03:50:10.0000] <zcorpan>
annevk: but you can do <slot><tr><td>x</slot> ?

[03:50:24.0000] <annevk>
zcorpan: ideally, yes

[03:51:55.0000] <zcorpan>
annevk: and what should validators complain about? for <template> the latest thinking is to basically not validate the subtree (but still report parse errors)

[03:52:22.0000] <annevk>
zcorpan: I should probably think through the parsing rules again though, to see if it actually makes sense to follow <template>

[03:52:51.0000] <annevk>
zcorpan: not sure, technically <slot> contents are fallback content, so you could validate with respect to the surrounding tree perhaps

[03:55:05.0000] <zcorpan>
hmmmm. ok. transparent content model maybe

[03:55:38.0000] <zcorpan>
MikeSmith: ^

[03:56:46.0000] <zcorpan>
MikeSmith: hsivonen: btw, i remember there being an online tool to dump only parse errors with the v.nu html parser. Is it still up somewhere?

[04:25:06.0000] <annevk>
Defining a new element is hard

[04:25:29.0000] <annevk>
Hixie_ deserves much respect for figuring out over a 100

[04:44:30.0000] <annevk>
hayato: are you around?

[04:44:40.0000] <annevk>
hayato: I can't find the issue where we discuss the default rendering of <slot>

[05:04:37.0000] <annevk>
zcorpan: so given that attachShadow() comes with restrictions you could come up with restrictions on <slot> too that match that, but it'll get complicated quick

[05:21:34.0000] <nox>
zcorpan: What's the <template> content model bug?

[05:38:37.0000] <hsivonen>
zcorpan: thanks. the watchdog has automatically brought the service back up, but I need a faster watchdog

[05:39:27.0000] <hsivonen>
zcorpan: I don't recall an error dumper, but there's https://parsetree.validator.nu/

[05:46:16.0000] <nox>
What should { elem.classList = "foo bar foo"; elem.classList.replace("foo", "qux"); return elem.classList.value; } return?

[05:49:01.0000] <annevk>
nox: suspect "quz bar"

[05:49:21.0000] <nox>
annevk: Doesn't seem specified to me.

[05:49:33.0000] <nox>
"Replace token in tokens with newToken."

[05:50:42.0000] <annevk>
nox: why isn't it specified?

[05:51:15.0000] <nox>
annevk: I mean in the spec.

[05:51:34.0000] <annevk>
nox: I think it is

[05:52:03.0000] <nox>
annevk: When removing duplicate tokens in `remove`, we specify 'For each token in tokens, remove token from tokens.',

[05:52:28.0000] <nox>
when replacing in `replace`, we specify 'Replace token in tokens with newToken.',

[05:52:37.0000] <nox>
to me it sounds like it should become "qux bar qux".

[05:52:39.0000] <annevk>
nox: there are no duplicate tokens though

[05:53:29.0000] <nox>
What do you mean?

[05:53:59.0000] <annevk>
nox: why would there be duplicate tokens after they are parsed?

[05:54:52.0000] <annevk>
Maybe remove should not account for duplicates

[05:55:03.0000] <nox>
annevk: Oh I see.

[05:55:15.0000] <nox>
"If the collected string is not in tokens, append the collected string to tokens." in the ordered set parser.

[06:01:57.0000] <zcorpan>
annevk: https://github.com/whatwg/html/issues/541

[06:03:00.0000] <annevk>
zcorpan: that seems reasonable for <template>

[06:03:37.0000] <annevk>
zcorpan: the weird thing with <slot> that makes it trickier too is that it's actually non-conforming for it to appear in a normal document (except perhaps inside <template> contents)

[06:03:48.0000] <annevk>
zcorpan: it's only useful in a shadow tree

[06:04:18.0000] <annevk>
zcorpan: so unless the validator is integrated in the browser, you cannot meaningfully check its conformance

[06:04:44.0000] <zcorpan>
annevk: integrated in the browser is something i hope will happen

[06:06:14.0000] <zcorpan>
annevk: the first step of attachShadow could be made laxer if <slot> is parsed more like <template> though?

[06:07:26.0000] <annevk>
zcorpan: they're not tightly related

[06:08:05.0000] <zcorpan>
hsivonen: thanks! i don't know if i caused the 502 but it started right after i tried to guess the URL to parsetree (with some unknown path for validator.nu)

[06:08:29.0000] <annevk>
zcorpan: it's mostly about elements having complex requirements, perhaps builtin shadow tree, vs guaranteed to be simple without builtin shadow tree

[06:10:51.0000] <zcorpan>
annevk: ok. i think i need to take a day to read all the shadow specs to understand what's going on here :-)

[06:11:46.0000] <annevk>
That'd help

[06:16:56.0000] <zcorpan>
if we make <slot><tr> work i think we should also make <foo-bar><tr> work, otherwise people will use <slot> all over the place to take advantage of the better parsing

[06:21:55.0000] <annevk>
zcorpan: add a longer form of that argument to https://github.com/w3c/webcomponents/issues/59?

[06:30:50.0000] <SimonSapin>
jgraham: cProfile says that wpt/lint spends 32% of its time in html5lib’s detectEncoding. Would it be wrong for the lint to assume everything is UTF-8 ?

[06:31:16.0000] <jgraham>
SimonSapin: Yes

[06:31:33.0000] <jgraham>
some things quite intentionally aren't

[06:32:10.0000] <jgraham>
Although you could perhaps try making it assunme utf8 and fall back to not-utf8 if parsing fails

[06:32:26.0000] <jgraham>
For some definiton of "fails"

[06:33:11.0000] <SimonSapin>
ok, that sounds uncertain enough that it’s not worth it. thanks

[07:13:19.0000] <annevk>
Domenic: https://github.com/w3c/webcomponents/issues/59#issuecomment-199831277

[07:13:51.0000] <Domenic>
annevk: yeah saw that. anything in particular for me to comment on?

[07:13:57.0000] <Domenic>
oh i guess making custom elements parse like slot

[07:14:09.0000] <annevk>
Domenic: exactly

[07:15:08.0000] <Domenic>
Let me check with the googlers...

[07:16:17.0000] <annevk>
Domenic: if logical properties exist now, I think we can remove a couple of those LTR-specific things

[07:18:03.0000] <nox>
https://github.com/heycam/webidl/pull/94 Is that blocked by something?

[07:19:05.0000] <annevk>
nox: heycam|away might know

[07:20:07.0000] <Domenic>
annevk: unclear to what extent they fully exist... although I think Firefox has been shipping a versino of them (behind a flag??) for a while

[07:22:00.0000] <annevk>
Domenic: Gecko has had prefixed versions for ages

[07:22:12.0000] <Domenic>
sure, so has chrome

[07:22:17.0000] <Domenic>
but not ones that match that spec

[07:49:22.0000] <MikeSmith>
zcorpan: reading scrollback about the validator thing. Is https://parsetree.validator.nu/ the thing you had been thinking of?

[07:50:05.0000] <zcorpan>
MikeSmith: yes

[07:50:09.0000] <MikeSmith>
ok

[07:50:10.0000] <zcorpan>
thx

[07:51:06.0000] <MikeSmith>
also yeah it would be nice to get the <template> document-conformance stuff in the spec updated

[07:52:13.0000] <MikeSmith>
happy to make the validator changes to conform to whatever we end up with in the spec

[07:53:02.0000] <zcorpan>
hmm wonder if https://parsetree.validator.nu/?parser=html5&content=<%21DOCTYPE+html><option>&submit=Print+Tree is per spec and if it's intentional

[07:53:10.0000] <zcorpan>
i mean that it's a parse error

[07:56:07.0000] <zcorpan>
i wish <dt>s in the spec had ids

[07:56:19.0000] <zcorpan>
"If there is a node in the stack of open elements that is not either a dd element, a dt element, an li element, an optgroup element, an option element, a p element, an rb element, an rp element, an rt element, an rtc element, a tbody element, a td element, a tfoot element, a th element, a thead element, a tr element, the body element, or the html element, then this is a parse error."

[07:57:00.0000] <zcorpan>
so a bug in v.nu. and i also need to add menuitem to this list

[07:57:40.0000] <zcorpan>
maybe factor it out

[08:10:04.0000] <annevk>
So, I landed something on master without review

[08:10:16.0000] <annevk>
Domenic: what to do?

[08:10:55.0000] <zcorpan>
git diff --color-words ❤️ (when there's rewrap)

[08:12:57.0000] <annevk>
/me checks that he didn't leave the tree burning

[08:13:04.0000] <annevk>
ok, that's all good

[08:13:09.0000] <Domenic>
annevk: this seems like a case where you open an issue asking for review. In more drastic circumstances (like when I accidentally landed some script evaluation stuff) you could either push a revert commit, or you could un-protect master, force-push to a previous state, and re-protect it.

[08:13:48.0000] <annevk>
Will do and then I'm going to take a break for a bit 😃

[08:14:18.0000] <annevk>
Things started getting so repetitive I forgot the branch making step

[08:46:35.0000] <zcorpan_>
MikeSmith: hsivonen: where should i file bugs about v.nu html parser? https://bugzilla.validator.nu/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=HTML%20parser ?

[08:58:29.0000] <hsivonen>
zcorpan_: in the HTML: Parser component on bugzilla.mozilla.org

[08:59:15.0000] <zcorpan_>
hsivonen: also if it's only about parse error vs. no parse error?

[09:00:12.0000] <zcorpan_>
hsivonen: about.validator.nu says "Bugs should be reported to Validator.nu Bugzilla." btw

[09:01:16.0000] <zcorpan_>
i meant https://about.validator.nu/htmlparser/ points to the link i gave above

[09:55:43.0000] <annevk>
Domenic: the slow review wasn't meant as critique

[09:56:01.0000] <annevk>
Domenic: it's just that I don't have a good system for landing a set of incremental changes

[09:56:15.0000] <Domenic>
annevk: hmm ok

[09:56:30.0000] <annevk>
Domenic: e.g., I want to revive how we do "effective script origin", but I first want to land the outstanding PRs

[09:57:02.0000] <annevk>
Domenic: I guess I could create a new branch that also contains those commits, but then it becomes like a house of cards (and also I don't really know how to do that just yet)

[09:59:06.0000] <zcorpan_>
annevk: git checkout -b fix-1; /* PR for fix-1 */ git checkout -b fix-2; /* while on fix-1, so becomes on top of fix-1, then PR for fix-2 */ ... i think

[09:59:57.0000] <jyasskin>
Chrome's depot-tools have some good tools for managing dependent branches: https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools.html

[10:01:20.0000] <Domenic>
annevk: yeah you can just branch of a previous branch. But, I'll try to focus on the origin stuff after I work through the easy stuff.

[10:01:29.0000] <Ms2ger>
OTOH, depot is horrible in general :)

[10:02:44.0000] <annevk>
Domenic: can you branch from two branches?

[10:02:57.0000] <annevk>
Domenic: anyway, seems icky, but maybe at some point

[10:03:11.0000] <Domenic>
annevk: not quite. I would just create a linear history of all the changes in the order you think they should be applied.

[10:04:07.0000] <Domenic>
annevk: I broke https://github.com/whatwg/html/pull/920 by force-pushing my local checkout. Can you re-force-push your with the fixed title and merge?

[10:04:17.0000] <annevk>
Domenic: yeah, if I knew what I was doing upfront that'd be easy, but it's often on the go

[10:04:33.0000] <Ms2ger>
Domenic, that does mean you need to PR them sequentially, though

[10:04:53.0000] <annevk>
Domenic: will unbreak

[10:04:57.0000] <Domenic>
Ms2ger: I figure we'll be sure to make it work while landing, but just for getting work up that people can critique, seems to be OK.

[10:05:30.0000] <annevk>
done

[10:14:13.0000] <smaug____>
has http://krijnhoetmer.nl/irc-logs/ stopped working

[10:14:34.0000] <annevk>
smaug____: yeah

[10:28:35.0000] <Domenic>
Anyone want to review https://github.com/whatwg/html/pull/884 btw?

[10:29:37.0000] <annevk>
Domenic: that change looked fine to me, I thought the problem was finding implementers

[10:29:56.0000] <Domenic>
annevk: it seems like a small enough bug we should just fix the spec and then file bugs on implementations (after doing some testing)

[10:30:10.0000] <annevk>
Domenic: although looking at it again I think you should add the word "exception" after the class name

[10:30:37.0000] <annevk>
Domenic: maybe assign it to junov?

[10:45:47.0000] <Domenic>
annevk: origins are not mutable right?

[10:47:21.0000] <Domenic>
annevk: ah i guess they are, that is how document.domain works

[10:47:49.0000] <Domenic>
annevk: would it be possible to make them immutable and then document.domain changes the origin to a value that is a copy but modified?

[10:48:30.0000] <annevk>
Domenic: my plan is to make a single field on origin mutable that document.domain can mutate

[10:48:34.0000] <Domenic>
annevk: hmm I guess per https://github.com/whatwg/html/issues/794 implementations don't do that

[10:49:19.0000] <annevk>
Domenic: the PRs just make sure we don't contradict implementations

[10:49:43.0000] <annevk>
Domenic: after that I'll merge effective script origin into origin

[10:52:08.0000] <annevk>
Domenic: is https://github.com/whatwg/html/pull/915 good now?

[10:52:32.0000] <Domenic>
annevk: no: "It's very weird how this (and set and "delete an existing named property") are dfn'ed. Can you fix them to be xrefs to the appropriate Web IDL concepts while you're fixing this up?"

[10:56:18.0000] <annevk>
Domenic: that comment is not in the PR?

[10:56:36.0000] <Domenic>
annevk: " domenic commented on an outdated diff an hour ago " last one

[10:56:40.0000] <annevk>
Domenic: it's also not immediately obvious to me what that means, guess I'll look tomorrow

[10:56:51.0000] <annevk>
Oh

[10:57:38.0000] <annevk>
Domenic: wouldn't that remove the links from the IDL fragment?

[10:59:08.0000] <Domenic>
annevk: hmmm I see. But for Window and Document we don't do that.

[11:00:06.0000] <Domenic>
annevk: hmm but we do for option and such

[11:00:32.0000] <Domenic>
annevk: I don't like this; these places aren't defining the term "set". But I guess we can keep it.

[11:00:56.0000] <annevk>
Domenic: sounds like a follow up issue to clean things up

[11:01:31.0000] <annevk>
Domenic: I can file one

[11:01:59.0000] <Domenic>
cool. I'll get back to merging your PRs

[11:13:42.0000] <Domenic>
annevk: you should be able to merge https://github.com/whatwg/html/pull/870 now

[12:12:14.0000] <annevk>
So close to a streak of 10, but my internet connection dropped

[12:12:25.0000] <annevk>
So now it's 12 commits today, with a streak of 9

[12:12:33.0000] <annevk>
For w3c/html

[12:12:41.0000] <annevk>
Euh, whatwg/html, lol

[13:39:54.0000] <smaug____>
the latest css for w3c specs is super annoying. Takes ages to load, and when it finally loads, the spec layout changes radically. So, not worth to start reading anything before the css has been loaded.

[14:06:22.0000] <TabAtkins>
smaug____: Takes ages to load? Shouldn't be any slower than it ever has been.

[14:06:44.0000] <TabAtkins>
(That said, avoiding relying on the w3c server for styles is why Bikeshed writes the styles in manually for EDs.)

[14:15:33.0000] <smaug____>
TabAtkins: for some reason has been slow here lately

[14:15:35.0000] <smaug____>
(in Helsinki)

[14:16:15.0000] <TabAtkins>
Also if you're experiencing slow loads *consistently* that implies they're not being reasonably cached, which is dumb.

[14:22:21.0000] <TabAtkins>
Well, the cache header only allows it to be cached for 6 hours.

[16:21:02.0000] <heycam>
nox: looking now


2016-03-23
[18:22:41.0000] <nox>
heycam: Great, thanks.

[18:40:54.0000] <TabAtkins>
Domenic: I accidentally fixed the "using [[DOM]] puts [WHATWG-DOM] in the biblio index" problem, while fixing another bug.

[18:41:44.0000] <TabAtkins>
(Whatever form you use in an explicit biblio ref is now used automatically by anything else that grabs the same biblio ref, whether through an aliased term or what-have-you.)

[23:42:21.0000] <annevk>
Is GitHub super slow today?

[01:38:02.0000] <annevk>
terinjokes: is https://github.com/whatwg/fetch/issues/259 something that's worth standardizing language for in the Console Standard?

[02:08:47.0000] <Ms2ger>
zcorpan, can I bug you about https://github.com/w3c/csswg-test/pull/1066 ?

[02:42:10.0000] <zcorpan>
Ms2ger: looking

[02:42:24.0000] <zcorpan>
what does this construct do again? https://github.com/w3c/csswg-test/pull/1066/files#diff-c8670d7412c9acf48f69da4f9aa995c0R39

[02:43:31.0000] <Ms2ger>
I suspect it returns matrix after calling f() on it, but do complain about it :)

[03:15:05.0000] <zcorpan>
ok reviewed

[03:21:53.0000] <Ms2ger>
Thanks

[05:50:47.0000] <annevk>
zcorpan: philipj: https://www.w3.org/Bugs/Public/show_bug.cgi?id=29018

[06:56:48.0000] <annevk>
Woohoo, less than 200 open legacy bugs

[07:13:13.0000] <philipj>
annevk: uh, yes, not sure what to do about that one, would need to redo testing to refresh my memory

[07:36:05.0000] <zcorpan>
gsnedders: jgraham: some of my <menuitem> tests fail in html5lib even though the Expected: and Received: are the same. Is that due to #errors being different, or something else?

[07:38:50.0000] <Ms2ger>
I think we might check the number of errors still?

[07:52:01.0000] <zcorpan>
https://github.com/html5lib/html5lib-tests/pull/72

[07:53:34.0000] <zcorpan>
happy eastern everyone! see y'all on wednesday

[07:54:53.0000] <wanderview>
annevk: if you get a sec, can you confirm that step 8 here should not copy the destination or type from the original request? https://fetch.spec.whatwg.org/#dom-request

[07:56:56.0000] <wanderview>
annevk: or maybe it should copy them... the fetch() method invokes the constructor immediately...  is it intentional to lose those values if a service worker does fetch(evt.request)?

[07:58:34.0000] <wanderview>
I'll write an issue... you can close if I'm just confused

[08:01:57.0000] <wanderview>
https://github.com/whatwg/fetch/issues/262

[08:10:41.0000] <annevk>
wanderview: that was intentional

[08:10:48.0000] <annevk>
wanderview: since destination affects the CSP policy

[08:11:07.0000] <wanderview>
annevk: right, but doesn't that break CSP for passthrough service worker requests?

[08:11:10.0000] <annevk>
wanderview: I can add a note about the things we don't copy intentionally I guess

[08:11:21.0000] <annevk>
wanderview: I don't think so

[08:12:08.0000] <annevk>
wanderview: the document that initiates the fetch will get the CSP policy applied it asked for, and then in the worker you'll get the CSP policy corresponding to destination ""

[08:12:54.0000] <wanderview>
annevk: so this assumes the worker has a different CSP policy?

[08:13:35.0000] <annevk>
wanderview: a service worker will always have its own policy afaik

[08:13:43.0000] <annevk>
wanderview: I think all workers do

[08:16:44.0000] <wanderview>
annevk: hmm, ok... not sure why marcos wanted the destination/type to propagate... might need you to comment on the gecko bug at some point

[08:20:37.0000] <annevk>
wanderview: left a comment

[08:21:22.0000] <wanderview>
where?

[08:22:09.0000] <Ms2ger>
Under the mat before your back door

[08:22:12.0000] <annevk>
wanderview: I got a collision with your comment, so I think I'll leave it now since you said effectively the same

[08:22:27.0000] <annevk>
wanderview: I'll add the extra bit I added to GitHub instead

[08:22:57.0000] <wanderview>
thanks

[08:34:32.0000] <Domenic>
annevk: https://github.com/whatwg/html/issues/929 seems bogus to me; can you take a look? The client is the worker, right? Which is a fine place to inherit HTTPS state from.

[08:44:21.0000] <annevk>
Domenic: the problem is that it does not have state yet, I discussed that case earlier with jwatt

[08:46:36.0000] <annevk>
Domenic: gotta go for a bit, one last thing

[08:46:55.0000] <annevk>
Domenic: it'd be ideal for Mozilla if custom elements was all done and sorted within the next couple of weeks

[08:47:16.0000] <Domenic>
annevk: hmm ok, good to know. can do, but why?

[08:47:29.0000] <annevk>
Domenic: if there's anything I can do let me know, I'll let it take precedence over the Shadow DOM work I've been doing

[08:47:49.0000] <Domenic>
annevk: it'll probably just be agressive reviews as I move things to HTML.

[08:48:21.0000] <Domenic>
annevk: next week has some TC39 meetings that might slow things down but rest of this week and the week after next I can make it my top focus

[08:49:06.0000] <annevk>
Domenic: there's a large number of Mozillians in Taipei that'll be doing more Gecko work and in a couple of weeks I believe wchen will be there to help them get started with this

[08:49:19.0000] <annevk>
Domenic: some of them, anyway

[08:49:36.0000] <annevk>
Domenic: so if the spec is mostly done, that's ideal

[08:49:44.0000] <annevk>
Domenic: I'll do another review tomorrow then

[08:50:12.0000] <Domenic>
annevk: biggest missing piece is still the custom element callbacks :-/. I'll hopefully at least get a start on that today/tomorrow

[09:37:19.0000] <annevk>
Domenic: what timezone is TC39 in?

[09:37:30.0000] <Domenic>
annevk: San Francisco

[10:39:36.0000] <tobie>
Is there a best practice for when you should be putting the dfn within WebIDL, compared to out of it?

[10:42:07.0000] <TabAtkins>
If you're specifically defining something, put the dfn near it, so the IDL will link to it.  You want anyone visiting the anchor to land on the definition.

[10:42:22.0000] <TabAtkins>
If it's more trivial, feel free to leave it in the IDL.

[10:44:13.0000] <tobie>
TabAtkins: ty

[10:45:10.0000] <tobie>
TabAtkins: asking because now my WebIDL in another spec references the dfn rather than the IDL, which is weird.

[10:45:23.0000] <TabAtkins>
Why weird?

[10:47:16.0000] <tobie>
TabAtkins: well, in interface AmbientLightSensor : Sensor {}; Sensor links to the dfn and not the IDL, which seems weird, no?

[10:48:27.0000] <TabAtkins>
Again, why weird?

[10:50:58.0000] <TabAtkins>
(Also, Sensor isn't in Bikeshed's db - you using local refs? Should I add something to Bikeshed's d?

[10:51:02.0000] <TabAtkins>
*db

[10:51:56.0000] <annevk>
tobie: that would be weird, yes

[10:52:04.0000] <tobie>
TabAtkins: Oh, so that might explain it.

[10:52:14.0000] <tobie>
annevk: OK, I thought so too.

[10:52:15.0000] <annevk>
tobie: class names should reference IDL

[10:52:41.0000] <TabAtkins>
I agree that an interface name isn't something that should be separated from its definition.

[10:53:04.0000] <tobie>
TabAtkins, annevk: sorry this is a combination of me not being super familiar with Bikeshed + me not being super familiar with spec editing. :)

[10:53:06.0000] <TabAtkins>
The most pertinent definition of "what this interface is" is the interface itself.  It's just a name given an object shape, unlike methods and attributes.

[10:53:47.0000] <annevk>
tobie: no need to apologize, we're all here to learn

[10:54:38.0000] <TabAtkins>
tobie: You're talking about this dfn, right? https://w3c.github.io/sensors/#sensor

[10:55:18.0000] <tobie>
TabAtkins: yes.

[10:56:01.0000] <tobie>
TabAtkins: it's extra confusing because I have a "sensor concept" which doesn't map the Sensor interface 1:1.

[10:56:16.0000] <TabAtkins>
Alright, so (a) Imma go pop that into Shepherd, and (b) feel free to file a bug asking for them to change that <dfn> to an <a>.

[10:56:46.0000] <TabAtkins>
You can ref me and Anne saying that interface dfns should be in the IDL, as the most useful "definition" of the term. ^_^

[10:58:18.0000] <tobie>
well, I wrote both, so I can go fix it myself. :)

[10:58:49.0000] <TabAtkins>
Ah, kk. ^_^

[10:58:59.0000] <TabAtkins>
In that case, is the desired shortname "sensor" or "generic-sensor"?

[10:59:51.0000] <tobie>
the latter.

[11:00:41.0000] <tobie>
you might want to wait before I pushed changes to fix this, then.

[11:00:50.0000] <tobie>
TabAtkins: ^

[11:01:04.0000] <TabAtkins>
Nah, it'll pick up the differences after you push them, it's fine.

[11:01:27.0000] <TabAtkins>
Specs that aren't in its CI notification structure get reparsed like once a day or something.

[11:02:05.0000] <TabAtkins>
/me is still sincerely wondering if he should take this part of Bikeshed on his own, rather than relying on Shepherd.

[11:02:41.0000] <tobie>
TabAtkins: cool, so how does it work, though. Will the IDL in the AmbientLightSensor spec, automatically link to the Generic Sensor one?

[11:03:00.0000] <TabAtkins>
Oh, you'll need to rebuild at some point to make that work.

[11:03:12.0000] <TabAtkins>
But right now you're probably relying on a local <pre class=anchors> block anyway, so wtv.

[11:04:28.0000] <tobie>
Mmm. I'm not sure I understand all of those subtleties.

[11:05:00.0000] <TabAtkins>
Okay. So.

[11:05:52.0000] <TabAtkins>
I just added the Generic Sensor spec to Shepherd a few minutes ago.  Shepherd will parse the spec and extract all its definitions, and repeat this about once a day or so iirc in case things change.

[11:06:14.0000] <tobie>
OK, I figured that part. :)

[11:06:58.0000] <TabAtkins>
Your Ambient Light Sensor spec was already linking to Generic Sensor.  Since it wasn't in Shepherd yet, it wasn't relying on Bikeshed's built-in autolinking database.  It was either doing a manual link (ewwwwww) or was using a <pre class=anchors> block to tell Bikeshed about some additional cross-spec refs it should know about, for the purpose of processing

[11:06:58.0000] <TabAtkins>
this spec.

[11:07:23.0000] <tobie>
OK, now I get it.

[11:07:56.0000] <tobie>
I guess what makes it weird is that I don't know upfront what spec is in shepherd in which isn't.

[11:08:13.0000] <tobie>
s/in/and/

[11:08:37.0000] <tobie>
So sometimes the magic works and sometimes it doesn't.

[11:09:00.0000] <TabAtkins>
Yeah, that's a bit of a problem.

[11:09:05.0000] <tobie>
For example, the permissions-API isn't in Shepherd, right?

[11:09:07.0000] <TabAtkins>
The interface isn't publicly available.

[11:09:24.0000] <TabAtkins>
Yeah, it's not.

[11:09:35.0000] <tobie>
TabAtkins: got it.

[11:10:17.0000] <TabAtkins>
You can always ask Bikeshed if it knows about a particular reference or not.  Just run: `bikeshed refs` (-h to see the arguments) and it'll list everything it knows matching that ref request.

[11:10:32.0000] <tobie>
OK, I see.

[12:01:14.0000] <smaug____>
annevk: rootNode can be consider stable, right?

[12:01:50.0000] <Domenic>
/me is suddenly tempted to bikeshed the name

[12:02:23.0000] <smaug____>
ha

[12:03:18.0000] <smaug____>
Domenic: don't even think about or I'll start complaining about Custom Element's callback names and functionality ;)

[12:03:36.0000] <Domenic>
smaug____: hahaha you got me

[12:07:08.0000] <smaug____>
s/consider/considered

[12:23:29.0000] <annevk>
smaug____: yes

[13:12:50.0000] <jyasskin>
TabAtkins: Can Shepherd handle ReSpec editors' drafts at all? It'd be nice to get the permissions API in there even if we have to use link-defaults a lot.

[13:13:12.0000] <jyasskin>
TabAtkins: Also, where's Shepherd's list of specs? I'd be happy to send pull requests instead of bugging you for each new spec.

[13:18:21.0000] <TabAtkins>
jyasskin: Only if the ReSpec spec has explicitly added decent metadata that Bikeshed understands. The format is well-documented now, but it's rather annoying to add by hand, so ~0 specs have done so.

[13:18:52.0000] <TabAtkins>
jyasskin: (Or if they happen to be using patterns similar to what Shepherd is using to extract definitions from CSS/SVG/HTML/a few others.)

[13:19:04.0000] <TabAtkins>
(It works better than I'd expect, but not "well".)

[13:19:24.0000] <TabAtkins>
The list of specs is stored in Shepherd's DB, only accessible via the admin interface which is obviously not public. :/

[13:19:43.0000] <TabAtkins>
You can also see it in processed form in Bikeshed's data files, the bikeshed/spec-data/specs.json file.

[13:20:06.0000] <TabAtkins>
But there's no PR bridge to it; I have to add things manually.

[13:20:19.0000] <TabAtkins>
(I'm wondering how to fix it, and will bug plinss about it today.)

[13:21:11.0000] <TabAtkins>
Well actually, that's not true, there's a public API to read the spec data from Shepherd.

[13:22:04.0000] <jyasskin>
Yeah. IIUC, from ReSpec specs we'd get a lot of non-exported 'dfn' references, but they wouldn't be marked as IDL.

[13:22:48.0000] <TabAtkins>
https://api.csswg.org/shepherd/ is the human-readable endpoint that describes the REST api.

[13:22:52.0000] <TabAtkins>
jyasskin: Exactly.

[13:23:50.0000] <TabAtkins>
If people did what they were *supposed* to and actually published the *processed* ReSpec documents, instead of their source files and a JS converter, this would be easy. ReSpec could use the same sorts of shorthands and such that Bikeshed does, and mark things up well.

[13:23:52.0000] <jyasskin>
Yeah, I'm looking more for a place to send PRs.

[13:23:54.0000] <TabAtkins>
But nah, people lazy.

[13:24:46.0000] <jyasskin>
Presumably Shepherd could run the JS for a page and then process the result.

[13:26:23.0000] <TabAtkins>
Theoretically, sure.

[13:26:53.0000] <TabAtkins>
Would require running things in Node and hoping that jsdom is up to the task, tho.  Shepherd is written in Python, so it'd need a language bridge, too.

[13:27:28.0000] <TabAtkins>
I'm bugging plinss now to see if we can have a GH repo be the "canonical" storage for the spec list.

[14:02:51.0000] <tobie>
TabAtkins: think you could take a quick look at https://github.com/w3c/ambient-light/pull/7/commits/fd7548a

[14:03:41.0000] <tobie>
TabAtkins: and tell me whether I should be getting auto links to SensorReading SensorOptions and the like? I'm clearly doing something wring and I have no idea what.

[14:03:48.0000] <tobie>
*wrong

[14:04:04.0000] <TabAtkins>
Will check in a few, currently walking to Starbucks to avoid the cleaners

[14:04:15.0000] <tobie>
TabAtkins: ty

[14:07:09.0000] <Domenic>
jsdom is always up to the task! <3

[14:07:48.0000] <Sebmaster>
^

[14:14:02.0000] <tobie>
TabAtkins: src file has now been merged here: https://github.com/w3c/ambient-light/blob/gh-pages/index.bs

[14:14:48.0000] <tobie>
TabAtkins: note the index.html is the old Respec doc, so don't be surprised if the two are disconnected for now.

[14:16:44.0000] <wanderview>
jsbell: can you remind me where in the chromium tree your wpt service worker tests are?

[14:17:08.0000] <wanderview>
I can't seem to find the right path and the source viewer doesn't seem to have a search box any more

[14:17:29.0000] <jsbell>
wanderview: third_party/WebKit/LayoutTests/http/tests/serviceworkers and cachestorage

[14:17:33.0000] <wanderview>
thanks!

[14:17:56.0000] <jsbell>
wanderview: https://cs.chromium.org (cs=codesearch)

[14:18:16.0000] <wanderview>
jsbell: ah, that helps... I followed the "browse source" link by accident

[14:18:19.0000] <wanderview>
instead of the search source

[14:18:28.0000] <jsbell>
np!

[14:19:01.0000] <wanderview>
jsbell: btw, I am close to upstreaming our tests... are you ok if I just do that and then we can hash out any differences in PRs?

[14:19:09.0000] <wanderview>
I've probably asked you this before... sorry for the repeat

[14:19:24.0000] <jsbell>
wanderview: yep, sounds good

[14:19:53.0000] <wanderview>
thanks again!

[14:21:09.0000] <TabAtkins>
tobie: How do you want comments, now that it's been merged?

[14:21:41.0000] <tobie>
TabAtkins: can't you still comment on the PR?

[14:21:54.0000] <TabAtkins>
I can, yeah. Just asking you whether that was good. Sounds like it is. ^_^

[14:22:28.0000] <tobie>
yeah, whatever's more convenient for you.

[14:23:13.0000] <tobie>
here's fine too, depending on what it is you need to say

[14:27:32.0000] <tobie>
oh!! dfn

[14:27:52.0000] <tobie>
TabAtkins: dfns aren't exported by default

[14:27:57.0000] <tobie>
Now I get it.

[14:28:12.0000] <TabAtkins>
dfn-type dfns.

[14:28:12.0000] <TabAtkins>
(Which <dfn>s are if you dont' specify a different type.)

[14:28:32.0000] <TabAtkins>
When fully expanded, <dfn data-dfn-type=dfn>. ^_^

[14:29:32.0000] <tobie>
I--

[14:30:05.0000] <tobie>
Maybe I should re-read the doc another 3 times.

[14:30:07.0000] <TabAtkins>
Yeah, I know. Badly named. Can't fix it now.

[14:30:14.0000] <TabAtkins>
Really annoying to talk about and I hate it.

[14:31:03.0000] <TabAtkins>
Something like <dfn interface> (or when expanded, <dfn data-dfn-type=interface>) *are* exported by default.  It's just the "dfn"-type ones that are treated different for exporting.

[14:31:22.0000] <tobie>
BTW, I wasn't really asking for a review of this src file, more of an explanation as to why there wasn't auto-links to the stuff defined in the generic sensor spec.

[14:32:03.0000] <tobie>
And it seems that's because I've using DFN's for interfaces, and those aren't exported by default

[14:32:32.0000] <TabAtkins>
They're the wrong type, and *also* as a result of that they aren't exported, yeah.

[14:32:53.0000] <TabAtkins>
The fact that they're not exported isn't why your autolinks are failing, tho, it's that they're not the right type.

[14:33:25.0000] <tobie>
https://github.com/w3c/sensors/blob/gh-pages/index.bs#L648

[14:33:27.0000] <TabAtkins>
But it looks ok in the source - Sensor is defined with an "interface" type, as it should be.

[14:34:31.0000] <TabAtkins>
Are you generating your spec with a local copy of Bikeshed, or the remote version?

[14:34:42.0000] <tobie>
local

[14:35:01.0000] <TabAtkins>
Have you run `bikeshed update` some time after I put Sensors in the db?

[14:35:46.0000] <tobie>
mmm

[14:35:54.0000] <tobie>
yeah-ish

[14:36:19.0000] <TabAtkins>
May have been too early.  I just did it, and SensorReading is definitely in the db now. Update again and it should get picked up.

[14:36:33.0000] <tobie>
Amazing if it is.

[14:36:40.0000] <TabAtkins>
Why amazing?

[14:37:14.0000] <tobie>
Because it's 10:30pm and I'm tired. :)

[14:37:41.0000] <TabAtkins>
Oh, amazing as in "I'll be happy if so", not "that would be surprising"

[14:38:18.0000] <tobie>
yeah--sorry.

[14:38:22.0000] <tobie>
It works.

[14:38:38.0000] <tobie>
Also it's amazing because it's actually pretty cool tech.

[14:38:39.0000] <tobie>
:)

[14:39:25.0000] <TabAtkins>
Cross-spec autolinking is literally the reason I wrote Bikeshed.  It is pretty cool. ^_^

[14:39:43.0000] <tobie>
indeed.

[14:40:23.0000] <tobie>
OK, so I'll need to export dfns I want to reference in the AmbientLight spec

[14:40:45.0000] <tobie>
And should leave the dfn with the WebIDL for the interfaces

[14:40:53.0000] <TabAtkins>
Yeah. If you don't you can still link them, but you need to declare that you really do mean to link that spec, usually through a link-defaults block.

[14:40:54.0000] <tobie>
And then it'll be all good.

[14:41:09.0000] <TabAtkins>
Which is annoying if the term is *meant* to be generally useful for other specs.

[14:41:24.0000] <tobie>
OK. Got it.

[14:41:31.0000] <tobie>
Thanks so much for your help.

[14:42:56.0000] <TabAtkins>
np

[14:43:02.0000] <TabAtkins>
Glad to help the ecosystem grow.

[15:24:36.0000] <Krinkle>
Woo. https://w3c.github.io/webstorage/#dom-localstorage points to https://html.spec.whatwg.org/multipage/webstorage.html

[15:34:13.0000] <tobie>
TabAtkins: curious as to why https://w3c.github.io/sensors/#high-vs-low-level [GEOLOCATION-API] ends up as [geolocation-API] in the ref section.

[15:34:27.0000] <tobie>
TabAtkins: https://w3c.github.io/sensors/#biblio-geolocation-api

[15:36:42.0000] <tobie>
TabAtkins: sure, the shortname is mixed-cased, but my local ref isn't.

[16:29:04.0000] <TabAtkins>
tobie: Because the ref index uses the casing from SpecRef if it's mixed-case, in case that's important.

[16:29:14.0000] <TabAtkins>
(It uppercases things that are all-lowercase.)

[16:30:28.0000] <tobie>
TabAtkins: oh, right, because you're not using the specref service

[16:30:53.0000] <TabAtkins>
Well, I'm calling SpecRef for its data.

[16:30:58.0000] <tobie>
TabAtkins: the service is case-insensitive and generates an alias on the fly

[16:31:14.0000] <TabAtkins>
duuuuude, store the casing you want *in the db*.

[16:32:04.0000] <tobie>
TabAtkins: well... depending on the use case, having the actual shortname casing is important

[16:32:22.0000] <TabAtkins>
Then don't complain when I preserve it. ^_^

[16:32:57.0000] <TabAtkins>
(Bikeshed is also case-insensitive for *looking up* refs. It just preserves the casing for display if it surmises that it's important, such as when the casing is mixed.)

[16:33:03.0000] <tobie>
Well, sticking references in a spec isn't one of those use cases. :P

[16:33:18.0000] <TabAtkins>
Mang I can't tell that.

[16:35:10.0000] <tobie>
It's not that important tbh, but I do think the casing displayed in the ref section should match that used in the body of the spec

[16:35:32.0000] <tobie>
i.e. those references are internal

[16:36:07.0000] <TabAtkins>
I can probably do that, given the way I'm handling "preferred" names now.


2016-03-24
[18:22:35.0000] <Domenic>
tobie: what's the status on getting https://github.com/tobie/specref/pull/250 re-landed? What broke in prod, and can I help fix it?

[04:34:14.0000] <nox>
TabAtkins: Is element.matches("> *") supposed to be valid?

[04:37:26.0000] <nox>
TabAtkins: Seems like that method didn't get updated in DOM to use "Parse A Relative Selector" instead of "Parse a Selector".

[06:48:15.0000] <tobie>
Domenic: Some aliasing is broken somewhere. I'd need to think it through again and make sure I'm around to check the logs when we push it.

[06:59:57.0000] <annevk>
philipj: around? Any more thoughts on https://github.com/whatwg/html/pull/695?

[07:39:21.0000] <Domenic>
tobie: hmm I guess I was hoping I could stand up a server locally and debug failures

[07:47:13.0000] <tobie>
Domenic: you could of course totally do that. Don't know what I was thinking.

[07:47:24.0000] <tobie>
Domenic: I obv have a bit much on my plate atm.

[07:47:46.0000] <gsnedders>
/me buys tobie a bigger plate

[07:49:07.0000] <tobie>
gsnedders: ty

[07:49:48.0000] <gsnedders>
tobie: I'm always here looking for useful suggestions

[07:50:12.0000] <tobie>
Domenic: I can't remember the precise issues I was having, and the logger I use doesn't keep more than 24hrs of logs in its free version

[07:50:36.0000] <tobie>
Domenic: it had to do with some alises being broken

[07:51:06.0000] <Domenic>
tobie: so e.g. browser around the site and watch the logs for errors with the word "alias" in them>

[07:51:10.0000] <Domenic>
?

[07:51:13.0000] <tobie>
Domenic: possibly because of calling the search API used by specref.org

[07:51:20.0000] <Domenic>
hmmm

[07:52:16.0000] <tobie>
well, just run node index.js with whatever old version of node this thing requires

[07:52:38.0000] <tobie>
then just curl the different APIs for stuff related to the changes

[07:52:55.0000] <tobie>
Domenic: iirc it failed spectacularly and pretty quickly too

[07:53:33.0000] <Domenic>
philipj: how can you not think the warning helps for sync XHR given this trendline? https://www.chromestatus.com/metrics/feature/timeline/popularity/465

[07:54:05.0000] <Domenic>
philipj: at this rate it should be at 0 in 1.5 more years, literally!

[07:55:50.0000] <gsnedders>
Domenic: I can't imagine it dying till Fetch because practically usable

[07:55:54.0000] <annevk>
that alone shows how much the warning is worth

[07:56:03.0000] <annevk>
so much less synchronous IO

[07:57:16.0000] <tobie>
when was the warning introduced?

[08:02:52.0000] <annevk>
Quite a while ago, and every now and then someone gets upset with it and tells me how wrong I am and that for their particular niche synchronous IO is justified

[08:03:24.0000] <annevk>
Heck, even Brendan wants me to remove the warning

[08:04:16.0000] <gsnedders>
imo the big advantage of sync IO is the reduction of boilerplate with XHR

[08:05:01.0000] <tobie>
so why does this graphic prove that the warning has had an impact?

[08:05:02.0000] <annevk>
tobie: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg232

[08:06:05.0000] <tobie>
All I'm seeing is a initial spike which is probably when the fist measures where taken, followed by a regular gradual decline.

[08:06:57.0000] <tobie>
To prove the warning works, you'd need a measurable acceleration in decline from the point at which it was introduced, no?

[08:07:37.0000] <annevk>
tobie: why?

[08:07:43.0000] <gsnedders>
there's been plenty of other evangelisation about the badness of sync IO

[08:08:04.0000] <gsnedders>
hence I'm with tobie here, the causation hasn't been shown

[08:08:12.0000] <tobie>
gsnedders: precisely.

[08:09:30.0000] <annevk>
I guess that's fair

[08:10:59.0000] <annevk>
I've seen plenty of anecdotal evidence that this warning helps folks decide, but I guess you can't really tell from that graph per se

[08:19:53.0000] <Domenic>
It certainly isn't hurting

[08:26:08.0000] <jyasskin>
mounir: Have you figured out which version of Tidy you're running yet?

[08:26:56.0000] <jyasskin>
It's frustrating to have https://github.com/w3c/permissions/blob/gh-pages/contributing.md tell me to use it, and then have patches rejected because I did.

[08:35:12.0000] <annevk>
Domenic: I care quite strongly about moving towards "then"

[08:35:16.0000] <annevk>
Domenic: 😃

[08:35:34.0000] <annevk>
Domenic: was there anything else that I missed due to it being hidden or can I land?

[08:35:57.0000] <Domenic>
annevk: I'd like to do a second pass later today, sorry

[08:36:19.0000] <annevk>
Domenic: sure, no rush

[08:46:44.0000] <annevk>
We're at a low point for outstanding PRs btw, been a while

[09:02:04.0000] <Domenic>
yeah it warms my heart

[09:59:27.0000] <annevk>
"195 bugs found." \o/

[09:59:37.0000] <annevk>
Of course, we now have well over 200 issues...

[10:12:34.0000] <philipj>
Domenic: I don't doubt that it has *some* effect, but there are non-deprecated things that are also slowly decreasing and I've never been able to see a clear connection between deprecation date and change in usage for anything else, so I just don't know what explains the decreasing usage

[10:13:28.0000] <philipj>
Whatever is driving the decrease, I'd expect it to show some kind of half-life decay and not linear decrease, so getting down to 0.01% or could take a very long time.

[10:13:50.0000] <philipj>
So, I think something more aggressive will be needed to get anywhere with this in a reasonable time frame

[10:14:55.0000] <philipj>
Maybe setting a timeout that's continuously decreased so that only 0.01% of page loads have a synx XHR timeout because of it, so that it's less and less reliable

[10:15:00.0000] <Domenic>
philipj: you don't buy my trendline argument that we only need 1.5 more years? :)

[10:15:49.0000] <philipj>
Domenic: oh, didn't realize you were bein tongue in cheek :)

[10:18:07.0000] <philipj>
one could also imagine an intervention where certain user interactions cause a timeout, but that might not be fun to debug for developers

[10:22:40.0000] <gsnedders>
philipj: you're still at Opera, right?

[10:24:38.0000] <annevk>
Is SharedWorker still not supported outside Window? https://www.w3.org/Bugs/Public/show_bug.cgi?id=28504

[10:25:47.0000] <annevk>
TabAtkins: where is https://www.w3.org/Bugs/Public/show_bug.cgi?id=28080 tracked on the CSS side?

[10:27:49.0000] <TabAtkins>
nox: I'd think .matches() is *supposed* to use an absolute selector. Where's the context it would be applying a relative selector to? (It's not the element; that's checked against the resulting subjects of the selector.)

[10:28:35.0000] <gsnedders>
philipj: nvm, realised what I need probably wasn't on t anyway

[10:29:49.0000] <TabAtkins>
annevk: Hm, I dropped the ball on that, sorry. I'll bring it back up.

[10:42:38.0000] <philipj>
gnarf: yep!

[10:43:07.0000] <philipj>
I mean gsnedders ^

[10:43:34.0000] <philipj>
gsnedders: I assume you know about presto-testo though?

[10:45:30.0000] <annevk>
Domenic: does your blocked element thing supersede https://www.w3.org/Bugs/Public/show_bug.cgi?id=23960?

[10:46:39.0000] <Domenic>
annevk: not really. Although the delegatesFocus stuff for shadow DOM might help a lot.

[10:48:48.0000] <annevk>
slightlyoff: do you know if anyone from Google is working on an undomanager? https://www.w3.org/Bugs/Public/show_bug.cgi?id=14337#c14

[10:48:50.0000] <gsnedders>
philipj: yeah

[10:49:12.0000] <gsnedders>
philipj: tl;dr: was thinking I wanted stuff from t/resources, actually need stuff from spartan-server

[10:54:02.0000] <philipj>
gsnedders: I'm not sure that's around any longer

[10:57:04.0000] <gsnedders>
philipj: oh, it will be

[11:01:10.0000] <annevk>
Domenic: also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24718 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=24720

[11:12:11.0000] <Domenic>
annevk: what replaced "in a composed document"?

[11:13:27.0000] <annevk>
Domenic: in a shadow-including document

[11:13:34.0000] <annevk>
Domenic: which in turn is defined in terms of shadow-including root

[11:13:58.0000] <annevk>
Domenic: both already in DOM

[11:14:01.0000] <Domenic>
\o/

[11:19:26.0000] <nox>
TabAtkins: There are varions tests with such selectors un WPT, hence the question.

[11:19:45.0000] <TabAtkins>
That sounds like a bug in the tests!

[11:31:03.0000] <Domenic>
annevk: it would be minorly helpful if you could define "connected"

[11:32:11.0000] <annevk>
Domenic: you mean the IDL attribute?

[11:32:25.0000] <Domenic>
annevk: nah just the concept. But presumably you'd do both at the same time.

[11:32:39.0000] <annevk>
Domenic: isn't the concept just "in a shadow-including document"?

[11:33:13.0000] <Domenic>
annevk: hmm I guess so. It would be nicer if the author-facing API matched the concepts.

[11:35:00.0000] <annevk>
Domenic: I can still rename that easily

[11:39:29.0000] <gsnedders>
TabAtkins: wait you have the power to necro stuff? shit.

[11:39:43.0000] <TabAtkins>
I am a great and powerful sorceror.

[11:54:54.0000] <nox>
TabAtkins: Ok.

[13:45:16.0000] <smaug____>
annevk: Domenic: has it been written down somewhere that boolean attributes should be avoided in APIs unless it is absolutely clear what true/false mean in that context?

[13:45:17.0000] <smaug____>
/me is looking at directory-upload spec, and proposes using dictionary for the recursive param, not a boolean

[13:46:17.0000] <Domenic>
smaug____: it's in Web IDL

[13:47:05.0000] <Domenic>
smaug____: oh, no, I am misremembering. Web IDL just warns against booleans defaulting to true.

[13:47:10.0000] <Domenic>
smaug____: http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html is my favorite reference, but maybe we should add it to https://w3ctag.github.io/design-principles/

[13:47:34.0000] <TabAtkins>
yes plz

[13:49:13.0000] <smaug____>
Domenic: thanks, http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html is a good one

[14:45:11.0000] <tobie>
+1

[14:45:39.0000] <tobie>
TabAtkins: just curious if you use boilerplate beyond what bikeshed offers for your CSS specs.

[14:45:50.0000] <TabAtkins>
In what way?

[14:45:55.0000] <tobie>
TabAtkins: I'm not starting to work on spec'ing the concrete sensors (Gyroscope, AmbientLight, etc.)

[14:46:27.0000] <tobie>
TabAtkins: and there's a lot of stuff that are going to be common to each, even though I've stuck as much of it as I could in the generic sensor spec.

[14:48:19.0000] <tobie>
TabAtkins: for example, they'll all need to define the following: https://w3c.github.io/sensors/#definition-reqs

[14:48:32.0000] <TabAtkins>
Okay, gotcha.

[14:48:46.0000] <TabAtkins>
No, I don't do anything else. Dont' need to - the existing CSSWG boilerplate is plenty.

[14:48:55.0000] <TabAtkins>
But if you need such, there are a few ways to do it.

[14:49:36.0000] <tobie>
TabAtkins: well, not only do I think it's worthwhile for me, it might also be something nice to offer other editor who want to expose sensors

[14:49:42.0000] <TabAtkins>
Most obvious is to set up some new boilerplate for yourself, derived from the dap boilerplate.  Adjust whatever's necessary.

[14:51:01.0000] <tobie>
TabAtkins: sure, but that's lightly different, though. I feel like I need scaffolding more than boilerplate

[14:51:01.0000] <tobie>
*slightly

[14:51:01.0000] <TabAtkins>
Another way, probably better for your needs, is to build an inclusion file, and just include that into your specs via a <pre class=include> (which I realized a few days ago wasn't documented).

[14:51:01.0000] <TabAtkins>
Hmm, scaffolding is *way* more difficult.

[14:51:01.0000] <TabAtkins>
Well, actually, maybe not. Depends on how complex you mean.

[14:51:24.0000] <tobie>
I'm not sure, yet, actually. :-/

[14:51:28.0000] <TabAtkins>
So, again this isn't documented yet because I'm a bad person, so bear with me, when including a file you can set up some custom macros that will be available inside the included file.

[14:51:46.0000] <TabAtkins>
So if it's it's just a matter of "here's a template, fill in the holes", then that's totally possible.

[14:52:05.0000] <tobie>
Maybe that's what I'm looking for.

[14:52:18.0000] <TabAtkins>
If it's any more diverse, tho, then there's really nothing that can be done mechanically, and the right thing is just to document what each specific sensor is expected to provide.

[14:53:20.0000] <tobie>
Sure. But it would be pretty cool if I could write the specifics of each as YAML or JSON or whatnot and have a whole bunch of things generated.

[14:54:09.0000] <TabAtkins>
Like I said, if it's just a matter of a template with holes that will be filled with text, I can do that.  (If the holes are *large* it's not *convenient* currently, but can be done.)

[14:54:38.0000] <TabAtkins>
Any more complex and I'd have to invent something new, and I'm wary to try and do that without more examples to inform the design.

[14:55:39.0000] <tobie>
oh, I wasn't asking for work on your side

[14:56:00.0000] <tobie>
Just curious as to what can be done with the existing tool and in which direction I should poke

[14:56:59.0000] <tobie>
I'll start off mostly manual with the first spec

[14:58:19.0000] <tobie>
then try to extract commonalities from it.

[14:58:19.0000] <tobie>
Thanks for the pointers

[14:59:20.0000] <TabAtkins>
np

[15:47:25.0000] <slightlyoff>
annevk: I don't. I think that stopped when rniwa went to apple


2016-03-25
[17:30:07.0000] <tobie>
Domenic: if there's ever a time where you want to have a look at the Generic Sensor API and comment, now (i.e. within the next 2 weeks or so) we would be about right.

[17:31:06.0000] <tobie>
https://w3c.github.io/sensors/ for the Generic Sensor ED and https://w3c.github.io/ambient-light/ for a first concrete sensor building on top of it.

[22:05:37.0000] <annevk>
slightlyoff: ta

[22:05:43.0000] <annevk>
Domenic: no review?

[22:14:51.0000] <gwicke>
hi, after reading https://github.com/whatwg/fetch/issues/66 I'm wondering if fetch responses with redirect: 'manual' might expose the response body some time in the future?

[22:16:51.0000] <annevk>
Hmm, https://github.com/heycam/webidl/issues/101

[22:17:42.0000] <annevk>
gwicke: only if we design a protocol for the server to opt into

[22:17:58.0000] <annevk>
gwicke: something like CORS, but for redirects

[22:19:02.0000] <gwicke>
even for same-origin requests?

[22:22:38.0000] <gwicke>
background: we have some REST API use cases in which the option to let the client opt out of redirects & access the response body instead would simplify caching

[22:26:57.0000] <annevk>
gwicke: yes

[22:27:22.0000] <annevk>
gwicke: https://fetch.spec.whatwg.org/#atomic-http-redirect-handling

[22:28:40.0000] <gwicke>
the example cited there is a cross-origin redirect; I have trouble seeing the issue if it's all within the same origin

[22:30:32.0000] <annevk>
gwicke: could be similar for same-origin with it redirecting to some token URL that you didn't expect would be exposed

[22:31:56.0000] <gwicke>
hm, okay

[22:34:33.0000] <gwicke>
using redirects to hide such information from XSS feels a bit odd, but the restriction makes sense with that goal as a background

[22:34:36.0000] <gwicke>
thanks!

[22:38:00.0000] <annevk>
gwicke: it's because we never exposed redirects that exposing them now would cause problems, that kind of design was really the goal I think

[22:38:18.0000] <annevk>
gwicke: we just didn't expose redirects quickly enough

[22:38:27.0000] <annevk>
gwicke: but maybe it's kind of nice that we didn't

[22:41:58.0000] <gwicke>
it's too late in any case if we assume that sites rely on this quirk for XSS protection

[22:54:02.0000] <annevk>
right, that's what I meant

[04:37:54.0000] <Guest45222>
hello #whatwg

[04:40:00.0000] <Guest45222>
looking at the spec around location interface and wondering the root cause of location's properties being unforgeable. I've seen lots of comments saying that it's for security purposes but no clear evidence to me.

[04:42:24.0000] <march__>
some evidence on google books but not mush http://bit.ly/1RD3PsH

[04:42:28.0000] <march__>
*much

[04:56:35.0000] <annevk>
march__: that's the reason

[04:56:46.0000] <annevk>
march__: plugins would read those properties and expect them to be accurate

[04:57:23.0000] <annevk>
march__: [Unforgeable] also makes them own properties, which is important for all the security checks in Location object's internal methods

[06:01:53.0000] <annevk>
How do you set something permanently on your PATH?

[06:08:45.0000] <annevk>
Anyone still familiar with the HTML parser that knows how to fix https://www.w3.org/Bugs/Public/show_bug.cgi?id=28433?

[06:22:11.0000] <march__>
thanks annevk for answer, this is exactly what i want to do : fool a script so it thinks that it's running somewhere else.

[06:22:58.0000] <march__>
my last hope is https://github.com/hackvertor/MentalJS/blob/master/javascript/Mental.js

[06:27:00.0000] <march__>
but it's quite ugly, too bad we can't sandbox properly third party scripts

[07:02:07.0000] <Domenic>
annevk: I nominate zcorpan for becoming the parser person :P

[07:32:29.0000] <MikeSmith>
nice to see the bugzilla count down as much as it’s gone down

[07:39:00.0000] <SimonSapin>
annevk: https://html.spec.whatwg.org/multipage/semantics.html#htmlhyperlinkelementutils seems to duplicate https://url.spec.whatwg.org/#api

[07:39:04.0000] <SimonSapin>
Is that intended?

[07:39:17.0000] <SimonSapin>
Are there differences?

[07:48:43.0000] <Ms2ger>
SimonSapin, https://github.com/whatwg/url/issues/62

[16:59:20.0000] <jyasskin>
TabAtkins: Feature request: add https://tc39.github.io/ecma262/ to Shepherd.


2016-03-26
[17:00:56.0000] <TabAtkins>
Ideally, yes.

[17:09:35.0000] <gsnedders>
this is wrt xref maangement?

[17:10:34.0000] <jyasskin>
Yeah, I don't want to have to define anchors for 'Realm' or 'global object' in every spec that uses the terms.

[17:11:10.0000] <jyasskin>
I'll still need link-defaults since they don't export any <dfn>s, but it's nicer not to have to find the URLs.

[17:11:34.0000] <gsnedders>
/me really just wants to get rid of Shepherd, or at least most of what it does

[17:18:31.0000] <jyasskin>
Heh. I just want Bikeshed to do the right thing. The backend is an implementation detail.

[23:24:38.0000] <annevk>
SimonSapin: yeah, we split the interfaces due to different implementations

[01:31:53.0000] <MikeSmith>
annevk: wondering if you share some of hsivonen’s views on possible problems with the client-hints header

[01:32:21.0000] <MikeSmith>
other than what you’ve expressed in https://github.com/whatwg/fetch/pull/258 and wherever

[01:51:43.0000] <annevk>
MikeSmith: I think content negotiation can work under limited circumstances today

[01:52:09.0000] <annevk>
MikeSmith: when tightly defined and with interoperable clients

[01:53:27.0000] <annevk>
MikeSmith: still complicated though, but CDNs and general server knowledge have advanced

[02:01:28.0000] <annevk>
gsnedders: make it happen


2016-03-27
[19:08:47.0000] <gsnedders>
annevk: I'm trying!

[01:33:08.0000] <annevk>
Domenic: do you also report the users that file bogus issues?

[01:33:29.0000] <annevk>
Domenic: I usually just report them and pass the link along to GitHub, they then remove the issue altogether

[03:52:54.0000] <nox>
annevk, TabAtkins: Selection is kinda broken in the DOM spec.

[03:53:23.0000] <nox>
Ah no, never mind, it's Safari that is broken.

[03:53:39.0000] <nox>
https://dom.spec.whatwg.org/#dom-nondocumenttypechildnode-nextelementsibling Triple clicking on that sentence somehow doesn't select it anymore.

[06:28:56.0000] <Domenic>
annevk: yep, reported

[08:09:54.0000] <annevk>
Great

[08:10:31.0000] <annevk>
I guess I might close them too going forward for signaling purposes

[12:12:39.0000] <dekiss>
where can I read the most recent http specification?

[12:21:38.0000] <dekiss>
I guess this is newwest? http://www.ietf.org/rfc/rfc2616.txt

[13:46:42.0000] <Domenic>
dekiss: see https://fetch.spec.whatwg.org/#references [HTTP]; it's a collection of new RFCs

[15:39:25.0000] <dekiss>
I am sending custom http request to my apache web server and I am pretty much sure the http request is well formed it has only http request header but in my apache logs there is the reqeust with code 400 which means it was bad request, why is that?

[15:40:34.0000] <dekiss>
I made custom web server and made request opening localhost with chrome browser and I copied the request that chrome sent to my server to make custom http requestto apache that is on my same machine, I am sending the custom reqeust with the web client that I made in c++


2016-03-28
[05:20:56.0000] <MikeSmith>
I somehow missed the news from earlier in the month about the alpha release of Servo being targeted for Jun

[05:21:02.0000] <MikeSmith>
*June

[05:45:41.0000] <annevk>
Interesting, hadn't heard about that either

[05:55:52.0000] <MikeSmith>
annevk: I guess https://groups.google.com/forum/#!topic/mozilla.dev.servo/dcrNW6389g4 where it’s mentioned just sorta in the context of giving a goal/deadline for getting those 4 sites working in Servo

[05:56:08.0000] <MikeSmith>
so maybe others are making a bigger deal out of it than was intended

[05:56:29.0000] <MikeSmith>
anyway, that’s a somewhat odd set of sites to target

[05:56:47.0000] <MikeSmith>
github, duckduckgo, hackernews, reddit

[05:58:50.0000] <MikeSmith>
I guess the pattern is clear enough but other than github it’s not exactly set of sites that are essential even to developers as a target for testing

[05:59:44.0000] <MikeSmith>
at least I think it would be better to target, say, stackoverflow, rather than hackernews or reddit

[06:00:14.0000] <MikeSmith>
or maybe they already have stackoverflow working

[07:31:00.0000] <smaug____>
Why is there "Elements" class?

[07:33:58.0000] <smaug____>
hmm, I guess no one supports queryAll

[07:43:45.0000] <wanderview>
annevk: JakeA: is case 4 of step 3.3 here correct? https://fetch.spec.whatwg.org/#http-fetch

[07:44:21.0000] <wanderview>
can a service worker do evt.respondWith(fetch(someUrlThatRedirects)) for a navigation request?

[07:44:51.0000] <annevk>
wanderview: how would url list have more than one item in that case?

[07:44:51.0000] <wanderview>
I mean, can a service worker really not do an evt.requestWith(fetch(someUrlThatRedirects)) for a navigation... that seems like a change from previous behavior

[07:45:14.0000] <annevk>
wanderview: oh, you don't pass redirect mode along

[07:45:16.0000] <wanderview>
annevk: the inner fetch() performed by the service worker gets redirected

[07:45:18.0000] <annevk>
wanderview: right, that wouldn't work

[07:45:28.0000] <wanderview>
annevk: why not?  this seems to have changed at some point

[07:45:50.0000] <wanderview>
annevk: why can't the service worker pass any response it pleases back?

[07:46:04.0000] <wanderview>
the manual mode stuff was added just to make pass through requests work

[07:46:06.0000] <annevk>
wanderview: that was a security issue I thought

[07:46:15.0000] <wanderview>
annevk: link?

[07:47:40.0000] <annevk>
wanderview: https://github.com/whatwg/fetch/commit/e54f6bd1e75f46cd4b8202f5ee3bfa68e9ded906

[07:48:23.0000] <wanderview>
annevk: thanks!

[07:49:19.0000] <smaug____>
annevk: do you recall where queryAll was designed/discussed? Just wondering about the Elements class

[07:50:33.0000] <annevk>
smaug____: www-dom?

[07:50:37.0000] <annevk>
smaug____: long time ago

[07:51:22.0000] <smaug____>
thanks. will look at there then (could not find anything in bug trackers)

[07:52:31.0000] <smaug____>
hmm, long ago. Somehow the API hasn't got much interest since then then, given that it hasn't been implemented, afaik

[07:52:46.0000] <annevk>
smaug____: it requires subclassing which we're waiting on

[07:53:00.0000] <annevk>
smaug____: I think generally people are pretty keen on having it, once that is there

[07:53:32.0000] <annevk>
smaug____: but it'll require some changes to IDL too and I should probably tweak a couple of aspects before this lands, maybe later this year all the infrastructure will be in place

[07:53:46.0000] <smaug____>
might be better to have implementable stuff in specs, and put ideas to some other document

[08:04:29.0000] <annevk>
yeah

[08:04:40.0000] <annevk>
Should probably remove it for now until the machinery is in place

[08:07:32.0000] <wanderview>
annevk: JakeA: do you have any opinion on this?  https://github.com/slightlyoff/ServiceWorker/issues/859

[08:07:41.0000] <wanderview>
we need to implement something soon here... we have the empty string behavior while chrome returns a real origin... causing a compat issue on a large site

[08:18:01.0000] <annevk>
wanderview: empty string is only the default for synthetic events

[08:18:17.0000] <annevk>
wanderview: when the specification creates and dispatches that event hopefully it sets it to a serialized origin?

[08:18:28.0000] <wanderview>
annevk: no, it doesn't as far as I can tell

[08:19:12.0000] <annevk>
wanderview: that sounds like a bug

[08:19:23.0000] <annevk>
wanderview: that description you quoted however is fine

[08:19:40.0000] <annevk>
wanderview: although these days defaults like that can go into IDL

[08:20:26.0000] <wanderview>
annevk: oh, it does set it

[09:08:58.0000] <tantek>
MikeSmith: by what criteria are those sites being proposed as "getting working" ? popularity? relevance? adherence to web standards? good examples of best practices?

[09:10:21.0000] <MikeSmith>
tantek: no idea

[09:10:25.0000] <MikeSmith>
suggest asking Paul

[09:10:29.0000] <MikeSmith>
Rouget

[09:11:01.0000] <tantek>
I guess I'd suggest alternatives to sites that seem to encourage toxic commentary (HN/Rdit)

[09:11:42.0000] <tantek>
but yeah, odd set

[10:29:40.0000] <dekiss>
can someone tell me which is the most recent tcp/ip adn http 1.11 specifications

[10:30:38.0000] <dekiss>
1.1

[10:31:15.0000] <annevk>
dekiss: someone gave you a pointer already for HTTP/1.1

[10:31:33.0000] <dekiss>
um?

[10:31:40.0000] <dekiss>
yesterday?

[10:31:56.0000] <annevk>
dekiss: yeah, Domenic pointed to https://fetch.spec.whatwg.org/#refsHTTP

[10:32:09.0000] <dekiss>
I am reading this but I wonder if there is newer http 1.1 spec https://tools.ietf.org/html/rfc2616

[10:32:27.0000] <annevk>
dekiss: did you follow the link?

[10:32:35.0000] <annevk>
dekiss: anyway, TCP is https://tools.ietf.org/html/rfc793

[10:32:43.0000] <dekiss>
yesterday some guys said that this link that I provided or rfc 2616 is most recent but they weren't sure

[10:33:00.0000] <annevk>
dekiss: that's not the most recent, see the link I gave

[10:33:05.0000] <dekiss>
I mean everything there is ok with today standards? because the spec is from 1999

[10:33:25.0000] <dekiss>
thanks man

[10:33:54.0000] <dekiss>
also I found a typing error in one w3 rfc document where to report it?

[10:34:26.0000] <annevk>
dekiss: also, at the top of the 2616 document you should see "Obsoleted by: 7230, 7231, 7232, 7233, 7234, 7235" which gives you an indication that it's not the latest

[10:34:39.0000] <annevk>
dekiss: it should say at the top

[10:35:17.0000] <dekiss>
I don't understand this https://fetch.spec.whatwg.org/#refsHTTP

[10:35:27.0000] <dekiss>
is http 1.1 spec now divided into more specs?

[10:35:46.0000] <annevk>
yes

[10:35:57.0000] <dekiss>
aham

[10:35:58.0000] <dekiss>
ok

[10:36:29.0000] <dekiss>
what is obsoloete by adn updated by

[10:36:52.0000] <annevk>
update is an amendment, obsolete is a replacement

[10:36:53.0000] <dekiss>
obsolete by means it is replaced by and update by means updates to the current doc?

[10:36:58.0000] <dekiss>
ye ok thanks

[10:48:09.0000] <dekiss>
I guess no one readed so they divided it by smaller parts hahah

[10:48:15.0000] <dekiss>
too big man :S

[10:50:18.0000] <annevk>
Domenic: so, I've been thinking a little bit about how to tackle navigate

[10:50:19.0000] <dekiss>
but it seems now the content is much bigegr

[10:50:42.0000] <annevk>
Domenic: my thinking is to slowly rewrite it, e.g., as a first step, introduce /browsingContext/ and /resource/ variables

[10:51:11.0000] <annevk>
Domenic: then make "exceptions enabled" an argument (probably an optional flag), etc.

[10:52:40.0000] <annevk>
Domenic: I guess the idea is to make it easier to grasp first, and fix second

[10:52:53.0000] <annevk>
in lots of tiny steps

[10:56:01.0000] <Domenic>
annevk: I don't actually remember navigate being broken... Lack of Fetch integration?

[10:56:52.0000] <annevk>
Domenic: it integrates with Fetch, but poorly, it accepts lots of different types as "new resource", none well explained

[10:57:24.0000] <annevk>
Domenic: the way it ends up creating new documents is done rather poorly editorially and the details of such creation acts are spread across the document

[10:57:42.0000] <Domenic>
annevk: could use some review of custom elements BTW. Custom element reactions (nee callbacks) are mostly good, just need to add IDL integration but it's very isolated. I'd like to start moving the DOM+ patches into DOM next week.

[10:57:48.0000] <annevk>
Domenic: afaik nobody implements it as written, though I'm not sure what the specific issues are

[10:58:11.0000] <annevk>
Domenic: okay, I looked through custom elements and it seemed mostly good

[10:58:43.0000] <Domenic>
Ah yeah the lack of explanation for navigating to non-HTML documents is not great, I remember that now.

[10:58:49.0000] <annevk>
It seems things have shifted around a bit again

[10:59:06.0000] <Domenic>
Yeah just consolidating everything into patches of existing specs.

[10:59:07.0000] <annevk>
Domenic: well, you can navigate to a URL, a response, a request, a history entry

[10:59:19.0000] <annevk>
Domenic: but navigate talks about them as if they're all identical

[10:59:27.0000] <Domenic>
Hmm I see.

[11:00:12.0000] <annevk>
Domenic: so is "create an element" the hook everyone is supposed to be using to create elements? If it is we might want it to be more convenient for other specifications to call

[11:00:36.0000] <Domenic>
Yeah it is. But not many specs should be creating elements. What were you thinking?

[11:01:04.0000] <annevk>
Mostly that document, prefix, and typeExtension could be defaulted

[11:01:20.0000] <Domenic>
How document?

[11:01:46.0000] <annevk>
global object's document

[11:02:09.0000] <annevk>
something similar to new Text() and new "PlatformObject" basically

[11:02:43.0000] <Domenic>
Mmm not a fan the global object stuff is too confusing  already. I'd rather keep that one explicit.

[11:03:18.0000] <annevk>
Yeah I guess that one is fine

[11:03:48.0000] <annevk>
DOM also started using "If ..., then ..."

[11:04:04.0000] <Domenic>
Seems reasonable to default the others I guess, although again there shouldn't be too many callers.

[11:04:54.0000] <Domenic>
When submitting the PR I'll try to match all the editorial stuff

[11:05:23.0000] <annevk>
Hmm so I gotta go, but I can do another look first thing tomorrow

[11:05:37.0000] <annevk>
If there's particular things you want me to look at let me know, apart from everything DOM+

[11:06:57.0000] <Domenic>
DOM+ will be first so that should be good for now. It's feeling pretty solid overall...

[12:22:42.0000] <gsnedders>
I'm getting an HSTS error on hitting https://www.whatwg.org/C

[12:23:02.0000] <gsnedders>
unknown issuer of the cert

[12:27:08.0000] <IZh>
Hi! My PDF making script currently fails because of: https://images.whatwg.org/robots.jpeg: warning: SSL certificate problem: unable to get local issuer certificat

[12:27:11.0000] <IZh>
e

[12:27:36.0000] <IZh>
The browser also says that a connection is untrusted.

[12:27:46.0000] <IZh>
The problem happens only with this image.

[12:28:25.0000] <gsnedders>
Hixie_: ^^

[12:28:34.0000] <IZh>
The other iimages are loading from html.spec.whatwg.org.

[12:29:07.0000] <IZh>
Domenic: ^

[14:05:40.0000] <annevk>
gsnedders: IZh: DreamHost hardcoded the intermediate Let's Encrypt certificate so now things are failing

[14:06:13.0000] <annevk>
gsnedders: IZh: https://community.letsencrypt.org/t/certificates-issued-by-lets-encrypt-authority-x3-not-valid-in-mozilla/13320

[14:22:16.0000] <IZh>
annevk: Hmm... I thought that Let's Encrypt works well.

[14:22:34.0000] <IZh>
annevk: Anyway, why only that image is hosted on other site?

[14:23:48.0000] <IZh>
annevk: Could it be moved for a while to html.spec.whatwg.org?


2016-03-29
[18:15:34.0000] <michaelp_>
I'm having a bit of trouble understanding the entirety of CORS.

[18:15:53.0000] <michaelp_>
If i specify Access-Control-Allow-Origin header does it stop me requesting to myself, or does it simply add an allowance to request externally at the specified domain?

[18:16:17.0000] <michaelp_>
ie: If my browser is on michaelp.com and i specify Access-Control-Allow-Origin: michaelp.io can I still make XHR request against michaelp.com?

[18:16:54.0000] <MikeSmith>
michaelp_: yes

[18:17:03.0000] <MikeSmith>
it has no effect on same-origin requests

[18:20:13.0000] <michaelp_>
awesome, thanks!

[01:33:06.0000] <annevk>
I filed https://github.com/whatwg/html/issues/955 on moving robots.jpeg

[04:06:29.0000] <annevk>
Domenic: I reviewed the DOM bits

[05:09:09.0000] <annevk>
philipj: FWIW, if you could confirm in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28001 that that's what you had in mind that'd be great

[06:57:04.0000] <annevk>
smaug____: I commented out query/queryAll/Elements for now

[06:57:40.0000] <annevk>
smaug____: btw, if you could go through https://github.com/w3c/webcomponents/issues?q=is%3Aissue+is%3Aopen+label%3A%22needs+consensus%22 that'd be great

[06:58:10.0000] <smaug____>
thanks

[06:58:23.0000] <smaug____>
11 open, only

[06:58:27.0000] <smaug____>
surprising

[06:58:32.0000] <smaug____>
time to file some more :)

[06:58:44.0000] <annevk>
smaug____: 11 that need consensus :-)

[06:59:01.0000] <smaug____>
oh, that label

[06:59:03.0000] <annevk>
there's a bunch more with a plan of sorts

[06:59:14.0000] <annevk>
that just need fixing

[09:46:19.0000] <annevk>
mathiasbynens: so I don't think the regexp would need to account for TLD-specific restrictions

[09:46:49.0000] <annevk>
mathiasbynens: if we had to do that EAI would be impossible to validate

[09:47:33.0000] <annevk>
mathiasbynens: also, TLS-specific restrictions can't really apply to all labels in a domain, since you can just do whatever with subdomains

[11:03:14.0000] <smaug____>
anyone have contacts to Polymer team?

[11:03:20.0000] <smaug____>
or anyone from Polymer here?


2016-03-30
[00:33:27.0000] <annevk>
Domenic: not sure if it's all your work, but that custom elements introduction looks great

[00:33:44.0000] <annevk>
Domenic: reviewing the non-DOM parts for a bit

[02:53:46.0000] <Ms2ger>
annevk, ping

[02:53:56.0000] <annevk>
Ms2ger: hey

[02:54:19.0000] <Ms2ger>
The document.domain getter seems to put []s around ipv6 addresses now

[02:54:23.0000] <Ms2ger>
Was that intentional?

[02:56:17.0000] <annevk>
Ms2ger: yeah, I think that changed a while back

[02:57:10.0000] <Ms2ger>
jgraham, I don't suppose we can test that in wpt?

[02:57:11.0000] <annevk>
Ms2ger: see https://github.com/whatwg/html/issues/670

[02:58:11.0000] <Ms2ger>
annevk, great, thanks

[03:24:08.0000] <Ms2ger>
annevk, no luck for https://github.com/whatwg/html/issues/635 ? :)

[03:28:33.0000] <annevk>
Ms2ger: ftp/http/https check I guess, not sure if URL should have a primitive

[03:37:03.0000] <annevk>
Ms2ger: yeah, I guess I should add network scheme, and leave out ws/wss since they are pointless

[03:37:23.0000] <annevk>
Ms2ger: will fix later today

[03:37:31.0000] <Ms2ger>
Thanks!

[03:46:10.0000] <jgraham>
Ms2ger: No ipv6 at the moment

[03:49:14.0000] <MikeSmit1>
jgraham: no ipv6 for what?

[03:49:31.0000] <MikeSmit1>
ah, see scrollback now

[03:50:26.0000] <MikeSmit1>
smaug____: Justin Fagnini from Polymer project was at some of the Web Components f2f meetings

[03:50:45.0000] <MikeSmit1>
can find an e-mail address for him if that’s all you want

[03:51:33.0000] <MikeSmit1>
I don’t know him so well personally, so if you want an actual intro, maybe annevk or Domenic can help

[03:59:26.0000] <annevk>
MikeSmit1: I am missing some context

[04:00:32.0000] <annevk>
Oh scrollback, doh

[04:02:32.0000] <smaug____>
MikeSmit1: I was just looking for some way to report about a bug in Polymer

[04:04:03.0000] <annevk>
smaug____: would love input in the slotchange issue

[04:09:56.0000] <smaug____>
annevk: I commented there

[04:10:05.0000] <smaug____>
annevk: if this is about the event

[05:10:36.0000] <annevk>
smaug____: yeah, no opinions on reusing mutation observers (or their infrastructure)?

[05:29:26.0000] <smaug____>
annevk: kind of mixed opinions :). It is not about any DOM mutation

[05:29:34.0000] <smaug____>
it is about distribution change

[05:30:34.0000] <smaug____>
and we'd need to then tell exactly what was changed

[05:30:40.0000] <annevk>
smaug____: I guess it's not strictly speaking insert/remove, but shadow DOM is part of the DOM

[05:31:00.0000] <smaug____>
and rniwa was worried about providing all the distributed nodes in the record or something

[05:31:40.0000] <smaug____>
I don't consider shadow DOM being part of DOM. DOM tree is DOM tree, and Shadow DOM is a layer on top of it

[05:32:15.0000] <annevk>
smaug____: maybe, but the DOM mutation algorithms specifically account for shadow roots

[05:32:41.0000] <annevk>
smaug____: and soon will probably have to be changed to account for slots too if we're doing something with this event, which it seems like we will

[05:33:03.0000] <smaug____>
I'm mostly talking about the concept

[05:33:07.0000] <smaug____>
of DOM and Shadow DOM

[05:33:32.0000] <annevk>
Sure, me too, I just view it differently I think

[05:34:21.0000] <annevk>
If Shadow DOM was just a layer on top, we wouldn't have to revise all existing features to account for it

[05:41:39.0000] <annevk>
TabAtkins: when will Shepherd next index HTML?

[05:41:59.0000] <annevk>
TabAtkins: I want to make use of the various new origin terms in other documents

[06:06:14.0000] <zcorpan>
who should review https://github.com/whatwg/html/pull/907 and https://github.com/html5lib/html5lib-tests/pull/72 ? should i ask for review in a comment in https://bugs.chromium.org/p/chromium/issues/detail?id=412945 ?

[06:07:09.0000] <zcorpan>
smaug____: ^

[06:07:57.0000] <smaug____>
my review queue is rather full atm

[06:08:42.0000] <zcorpan>
ok :-) do you happen to know someone who knows the parser and doesn't also have a full review queue?

[06:09:31.0000] <smaug____>
hsivonen?

[06:10:36.0000] <jgraham>
There are people who will admit to not having a full review queue?

[06:11:42.0000] <Ms2ger>
Huh

[06:11:58.0000] <Ms2ger>
zcorpan, is there no longer a spec for alternative style sheets?

[06:12:18.0000] <smaug____>
Ms2ger: you hate the new w3c stylesheet too?

[06:12:28.0000] <Ms2ger>
Meh

[06:12:29.0000] <zcorpan>
Ms2ger: there is, but the API is gone

[06:12:47.0000] <jgraham>
The new W3C stylesheet is surprisingly bad

[06:12:48.0000] <Ms2ger>
zcorpan, where is it, and why?

[06:13:34.0000] <zcorpan>
Ms2ger: since only gecko implemented it and nobody else has shown any interest in implementing the API

[06:13:51.0000] <Ms2ger>
Did you file a bug?

[06:17:26.0000] <zcorpan_>
i think i have, yeah, but need to dig to confirm. i brought it up on www-style a few years ago and there has been no movement afaict

[06:18:36.0000] <zcorpan_>
https://lists.w3.org/Archives/Public/www-style/2013Aug/0640.html

[06:28:06.0000] <Ms2ger>
zcorpan_, filed bug 1260720

[06:28:17.0000] <Ms2ger>
zcorpan_, so where is the spec for the feature?

[06:30:07.0000] <zcorpan_>
Ms2ger: https://drafts.csswg.org/cssom/#add-a-css-style-sheet et al. though there are various bugs especially around mutation of attributes and such

[06:30:27.0000] <zcorpan_>
Ms2ger: there's something in CSS2 talking about alternative stylesheets too I believe

[06:31:35.0000] <Ms2ger>
Aha

[06:33:21.0000] <Ms2ger>
/me finds https://github.com/whatwg/html/issues/848

[06:33:55.0000] <zcorpan_>
hmm CSS2 didn't have much on the topic

[06:34:20.0000] <zcorpan_>
though https://html.spec.whatwg.org/multipage/semantics.html#link-type-stylesheet

[06:35:35.0000] <zcorpan_>
loading stylesheets needs more love :-(

[06:37:22.0000] <Ms2ger>
I know the perfect person!

[06:38:12.0000] <annevk>
zcorpan_: could you confirm https://github.com/whatwg/html/pull/965#discussion_r57881425 please?

[06:38:43.0000] <annevk>
zcorpan_: ta

[06:38:53.0000] <zcorpan_>
annevk: sorry for the delay :-)

[06:39:06.0000] <annevk>
zcorpan_: no worries, I was taking a break anyway

[06:39:58.0000] <zcorpan_>
let me know if there's something else that needs my attention, i have too many notifications

[06:44:08.0000] <annevk>
zcorpan_: there's a bunch of issues and bugs assigned to you

[06:44:21.0000] <annevk>
zcorpan_: not sure about anything immediate though

[07:06:33.0000] <beverloo>
Suppose I have a worker that imports something with importScripts() (using a relative URL), which in turn imports another script using importScripts() (again using a relative URL)

[07:06:57.0000] <beverloo>
is the second import expected to be resolved against the first imported script's URL, or the worker's URL?

[07:08:18.0000] <beverloo>
Is this the "API base URL" definition, which would imply it's resolved against the worker global scope's URL?

[07:10:15.0000] <Ms2ger>
first imported script's URL

[07:10:31.0000] <Ms2ger>
At least, that's what it should do

[07:11:23.0000] <Ms2ger>
Seems like the spec is buggy

[07:11:41.0000] <beverloo>
It looks like Chrome does the wrong thing too

[07:12:24.0000] <Ms2ger>
I'm fairly certain Gecko gets this right

[07:14:02.0000] <Ms2ger>
https://github.com/whatwg/html/issues/969

[07:14:23.0000] <beverloo>
I'll run some more tests and file this against Chrome if it's broken. Thanks :)

[07:15:22.0000] <annevk>
Ms2ger: no, not against the script URL

[07:15:44.0000] <Ms2ger>
?

[07:15:53.0000] <annevk>
Ms2ger: that doesn't make much sense, we don't know what a given function is associated with

[07:16:06.0000] <annevk>
Ms2ger: URLs are always resolved against some thing grabbed from the global

[07:20:11.0000] <Ms2ger>
@import doesn't

[07:20:43.0000] <annevk>
Ms2ger: sure, statics are different, module script identifiers don't either

[07:21:03.0000] <Ms2ger>
Still seems very confusing

[07:21:07.0000] <annevk>
Ms2ger: but with executing scripts there's no reasonable way to determine what resource they come from

[07:21:20.0000] <annevk>
Ms2ger: this is no different in an HTML context

[07:21:52.0000] <annevk>
Ms2ger: if you have <script src=/test/> in / and that does fetch("x") it'll fetch /x and not /test/x

[07:22:24.0000] <Ms2ger>
/me will think about it some more later

[07:23:06.0000] <annevk>
Ms2ger: otherwise each function would have to keep some pointer to the script its associated with and it'll get harrier still if functions invoke each other from different files, etc.

[07:23:21.0000] <Ms2ger>
I guess that's true

[07:23:23.0000] <annevk>
Ms2ger: it'd also be incompatible with what Brendan et al shipped years ago

[07:52:02.0000] <Ms2ger>
> In general, Chrome engineers should only be implementing new APIs that have reasonable Explainer documents attached.

[07:52:07.0000] <Ms2ger>
Are they going to write them too?

[07:52:17.0000] <annevk>
beverloo: if you manage to get hold of jsbell, tell him I'll try put in some effort into the Storage Standard tomorrow

[07:52:42.0000] <annevk>
Ms2ger: not sure I'll put effort into that, not even sure Explainer documents are useful if they're not part of the specification; only a very select audience would see them

[09:15:53.0000] <TabAtkins>
annevk: Shepherd respiders everything (a) whenever anything in our CI gets updated (CSSWG, Houdini, FXTF), and (b) midnight pacific time

[09:16:53.0000] <annevk>
Hmm, so tomorrow things should work in theory

[09:17:08.0000] <annevk>
I've started putting data-export="" on a couple of things

[09:17:38.0000] <TabAtkins>
annevk: Cool! Unexported things from HTML are annoying. ^_^

[09:18:00.0000] <TabAtkins>
I'm still not 100% sure I made the right call in "dfn" terms being unexported by default (so "local" definitions wouldn't leak out accidentally).

[09:18:25.0000] <annevk>
I think typically I would have expected those to be exported actually

[09:18:51.0000] <smaug____>
/me wonders why  insertAdjacentText doesn't return the inserted text node

[09:19:18.0000] <annevk>
And actually, what probably would be best is export everything and require some kind of keyword for the other spec, as in <a spec=html>whatever term</a>

[09:19:32.0000] <annevk>
smaug____: I didn't try to question the design

[09:20:14.0000] <smaug____>
annevk: right. so the answer is "it's legacy stuff"

[09:21:02.0000] <annevk>
smaug____: yeah, I suppose

[09:21:29.0000] <annevk>
"Find the person at Microsoft who shipped this before going home early"

[09:21:55.0000] <annevk>
That's probably a little too mean

[09:22:17.0000] <annevk>
Everyone ships pretty poor APIs the web sometimes get stuck with

[09:22:52.0000] <smaug____>
annevk: so https://dom.spec.whatwg.org/#insert-adjacent doesn't actually return the element ever. It returns null in some cases, but not the element

[09:23:05.0000] <smaug____>
I assume the idea is to return whatever pre-insert returns

[09:23:34.0000] <annevk>
smaug____: my bad

[09:23:38.0000] <smaug____>
this is for  insertAdjacentElement case

[09:24:27.0000] <annevk>
smaug____: yeah, I'll fix

[09:24:40.0000] <annevk>
smaug____: yeah, *Text ignores the return value

[09:24:42.0000] <smaug____>
thanks

[09:30:18.0000] <annevk>
smaug____: https://github.com/whatwg/dom/commit/5790d7288f3970b27ec5ac81aad2662eddb94959

[09:32:40.0000] <TabAtkins>
annevk: Making cross-spec linking as seamless as possible was the entire point. That said, if you *do* always specify the spec, you never have to worry about exporting. ^_^

[09:33:21.0000] <annevk>
TabAtkins: yeah, except now the seamless aspect is often wonky with other specs taking over terms and such

[09:33:37.0000] <annevk>
TabAtkins: and requiring terms to be globally unique

[09:34:35.0000] <annevk>
TabAtkins: probably makes sense for CSS, but not sure it scales well beyond that

[09:35:21.0000] <TabAtkins>
Specs "taking over terms" accidentally was an impl mistake on my part, it doesn't happen any more.

[09:35:43.0000] <smaug____>
r+ (at least for the insert adjacent stuff. seems to have random other changes too)

[09:36:14.0000] <TabAtkins>
I've got a planned mechanism for handling obsoletion and *purposeful* takeover, but I haven't implemented it yet. Still slowly, cautiously, doing autolinking refactoring to make the code sane before I introduce another complication to the model.

[09:36:18.0000] <smaug____>
btw, we're getting wpt tests for this from a gecko patch

[09:36:25.0000] <annevk>
smaug____: great

[09:36:58.0000] <TabAtkins>
smaug____: I can hook you up with some polymer folks; I'm heading into the office with them today. I'll be there in about an hour. Whatcha need?

[09:36:59.0000] <annevk>
TabAtkins: e.g., what about this HTML fork done in bikeshed? It seems it hasn't caused problems yet, but what if they start making demands?

[09:37:38.0000] <annevk>
TabAtkins: or these EME folks who think they want to reference forked HTML despite it having all kinds of security issues

[09:39:27.0000] <smaug____>
TabAtkins: it was about https://bugzilla.mozilla.org/show_bug.cgi?id=1256031#c13

[09:39:53.0000] <TabAtkins>
annevk: I control the list of specs in Bikeshed, and I'm not going to put in both HTMLs unless/until the fork is resolved properly.

[09:40:03.0000] <TabAtkins>
(In other words, I'm only putting in one of them.)

[09:40:57.0000] <annevk>
I guess we'll find out if someone decides to try

[09:51:07.0000] <TabAtkins>
How they gonna try? They have to go thru me, or else just hand-author a <pre class=anchors> block.

[09:52:52.0000] <annevk>
TabAtkins: I mean when they try to go through you, agreed it's rather theoretical at this point

[09:53:17.0000] <annevk>
TabAtkins: btw, in case of conflicts you'll just have to use spec=""?

[09:53:40.0000] <TabAtkins>
Yeah. (Or resolve it document-wide with some link-defaults.)

[12:00:16.0000] <wanderview>
can we do this for all the whatwg specs in infrastructure? https://twitter.com/jensimmons/status/715017455349985280

[13:48:10.0000] <MikeSmith>
wanderview: I believe the (smartass) answer is, Patches welcome

[13:48:52.0000] <MikeSmith>
but agreed it would be a very good thing to have and I would personally be willing to put time into making it happen

[13:49:16.0000] <MikeSmith>
especially for the lerget-than-life HTML spec

[13:49:52.0000] <wanderview>
MikeSmith: I guess I was wondering if it would have to be on a spec-by-spec basis... or if things like Bikeshed could just automatically add support

[13:50:23.0000] <MikeSmith>
as far as Bikeshed I guess TabAtkins would know the answer to that

[13:50:45.0000] <MikeSmith>
but for the general case it seems like we sure could

[13:51:56.0000] <MikeSmith>
just by making a library and maybe needing to tweak that specs a bit so that they all do whatever consistently to make use of the hook into the library in the same way

[13:53:27.0000] <MikeSmith>
well that all sounds really abstract when I say it so it makes me think we should just start out by trying it with one spec

[13:55:40.0000] <MikeSmith>
Domenic: btw about the dfn-links-across-multipage I really wonder if can’t just do that by building a separate index at build time, of all the terms and all references to them

[13:56:26.0000] <wanderview>
MikeSmith: maybe in the... service worker spec

[13:56:33.0000] <MikeSmith>
heh

[13:56:41.0000] <MikeSmith>
yeah that would be appropriate of course

[13:56:53.0000] <MikeSmith>
the SW spec is not a WHATWG spec though

[13:57:06.0000] <MikeSmith>
it’s really a standalone thing

[13:57:12.0000] <wanderview>
MikeSmith: we talk about it a lot in this channel

[13:57:28.0000] <wanderview>
/me doesn't understand the political divisions...

[13:58:14.0000] <MikeSmith>
well I guess it’s in either Respec or Bikeshed now and W3C-branded (or at least a copy of it is), so not an island in the way it used to be

[13:59:04.0000] <MikeSmith>
wanderview: I do understand the political divisions and like political divisions elsewhere, there are reasons for them

[13:59:21.0000] <MikeSmith>
that doesn’t make the political divisions helpful though

[13:59:56.0000] <MikeSmith>
anyway to me we are all part of a single do-ocracy

[14:00:58.0000] <MikeSmith>
I mean, the people who are solving real problems and getting technologies for the Web created that actually ship and make a difference in people’s lives on scale

[14:01:02.0000] <wanderview>
yea... I try to ignore that stuff and try to just get stuff done

[14:01:07.0000] <MikeSmith>
yup

[14:01:39.0000] <MikeSmith>
editors make their own choices about where they want to do their work, and they should have to discretion to do that

[14:04:30.0000] <MikeSmith>
slightlyoff has his way with how/where he started the Service Workers spec, mkwst has his way of getting a lot of great work done in a W3C WG (despite the politicsーexploiting the W3C to its full potential)

[14:05:12.0000] <MikeSmith>
exploiting in a good wayーmaking the best use of what’s actually good and most helpful about the W3C

[14:06:12.0000] <MikeSmith>
and yoav is making stuff get done in the WICG

[14:08:02.0000] <MikeSmith>
and in some ways the entities everybody happens to work for are enlightened patrons with good sense to give people doing the work on specs (and tests) for the platform a lot of flexibility and trust

[14:08:53.0000] <MikeSmith>
no matter what place those people/editors choose personally at the place to do their work, be it WHATWG, W3C, WICG or whatever

[14:09:37.0000] <MikeSmith>
trust the editors to make their own choices about where they can get their work done the best

[14:11:30.0000] <MikeSmith>
btw TabAtkins is obviously also an example of solving real problems productively even within the W3C constraints/political culture

[14:11:38.0000] <MikeSmith>
maybe the best example

[14:11:43.0000] <MikeSmith>
anyway, end sermon :)

[14:14:32.0000] <MikeSmith>
Domenic: for the dfn things, to mitigate the performance suckage of having it regenerate, we could client-side cache/store each formatted one (for each term) the first time the reader clicks a term to create it

[14:14:37.0000] <wanderview>
MikeSmith: I wasn't trying to be negative... I just admit I don't know how things get most of the time :-)

[14:15:45.0000] <jgraham>
wanderview: "I wasn't trying to be negative" - ah, then I think you were offtopic

[14:15:47.0000] <MikeSmith>
wanderview: nah, I realize you weren’t trying to be negative. I guess some of what I said is a sub-remark for the channel related to discussions some of us have also been having elsewhere recently

[14:15:53.0000] <MikeSmith>
heh

[14:17:05.0000] <MikeSmith>
Domenic: I would guess that most readers only use the dfn feature with a handful of terms and then use it repeatedly with those terms

[14:17:59.0000] <MikeSmith>
Domenic: so it would be a waste anyway to pre-generate them all for every reader ahead of time, since they are never going to use most of them anyway

[14:18:27.0000] <MikeSmith>
anyway, I’m clearly just thinking out loud right now about it

[14:27:49.0000] <Domenic>
MikeSmith: hmm interesting. I guess ahead of time seems nicer in most cases, just maybe not for singlepage. Although I'd be curious about the numbers.

[15:18:01.0000] <littledan__>
mathiasbynens: What do you think of this? https://bugs.chromium.org/p/v8/issues/detail?id=4879 It seems like a bug to me, but I think you reported the opposite to Apple

[15:18:47.0000] <littledan__>
I can't imagine how case folding semantics should make /\W/ui.test("S") true. If the ES spec makes it true, that seems like a spec bug

[15:24:48.0000] <TabAtkins>
Hmmm, Bikeshed probably could. At least it could produce the scripts for you (opt-in, obviously). You still need to be on https, of course.

[15:25:04.0000] <TabAtkins>
MikeSmith: ^^^ (re: Bikeshed providing a SW for caching the spec)

[15:27:44.0000] <Domenic>
The real trick is to get your spec generator to cache everything on the same origin... which I guess doesn't work great for *.spec.whatwg.org, lolz. But w3.org would be in good shape.

[15:28:33.0000] <TabAtkins>
Yeah.

[15:28:43.0000] <Domenic>
(the idea being you can click on any cross-spec link and still have it work offline)

[15:28:51.0000] <jyasskin>
Obviously the specs should be on https. ;-)

[15:29:15.0000] <Domenic>
Otherwise a network attacker could trick browser vendors into implementing CORS wrong. I can see the CVE now...

[15:32:37.0000] <TabAtkins>
Ah, so Bikeshed would analyze the cross-spec links, and set up a script accordingly so that when you viewed that spec, it made caching-requests to the origin's SW. Then any future views will have all links working.

[15:33:04.0000] <Domenic>
ooh that's a cool idea

[15:33:13.0000] <Domenic>
i was thinking more simply some kind of w3.org-wide service worker that cached everything

[15:33:32.0000] <Domenic>
relevant: https://github.com/whatwg/resources.whatwg.org/issues/6 from 2015-05-15

[15:33:33.0000] <TabAtkins>
And once it's been loaded on one spec, unaware specs on the same origin will at least get the benefit of the SW's cache for the specs it's done caching for.

[15:33:46.0000] <Domenic>
also fun would be https://github.com/whatwg/resources.whatwg.org/issues/7

[15:33:55.0000] <TabAtkins>
I just can't analyze unaware specs for their *own* dependencies, as the SW can't reach across on its own.

[15:34:43.0000] <TabAtkins>
(Until you click something on one of them; the SW will intercept and cache that.)

[15:35:09.0000] <TabAtkins>
Unfortunate that the WHATWG specs can't all share a cache, tho. ;_;

[15:35:47.0000] <Domenic>
yeah dang

[15:36:26.0000] <TabAtkins>
Y'all done goofed.

[15:36:43.0000] <Domenic>
/me handwaves ... isolation is good?

[15:37:00.0000] <littledan__>
move SW to cookie-style isolation!

[15:37:14.0000] <Domenic>
I think storage.spec.whatwg.org is already eTLD+1 for some reason

[16:51:38.0000] <Domenic>
TabAtkins: any reason auto-linking wouldn't work for interfaces named %Uint8Array%?

[16:56:22.0000] <TabAtkins>
Domenic: I have restrictions on what's allowed in a recognized shorthand, and % isn't there. I can add it tho.


2016-03-31
[19:27:22.0000] <MikeSmith>
Domenic: > Otherwise a network attacker could trick browser vendors into implementing CORS wrong

[19:27:44.0000] <MikeSmith>
isn’t that what we /TR is for?

[19:27:51.0000] <MikeSmith>
(rimshot)

[23:52:13.0000] <mathiasbynens>
littledan__: Looks like Yang already answered while I was asleep. The TL;DR is https://mathiasbynens.be/notes/es6-unicode-regex#impact-i which is admittedly very subtle in the spec

[23:53:27.0000] <mathiasbynens>
littledan__: Thanks for the heads-up! Don’t hesitate to CC me on bugs like this.

[01:40:52.0000] <Ms2ger>
annevk, hey

[01:40:58.0000] <annevk>
MikeSmith: SW kinda depends on Fetch and HTML though, which is why it often comes up here, not too standalone I'd say

[01:41:08.0000] <Ms2ger>
Is it safe to pass a DOMString to https://encoding.spec.whatwg.org/#utf-8-encode ?

[01:42:10.0000] <MikeSmith>
annevk: I meant standalone in terms of having started from slightlyoff’s own github account rather than a particular org

[01:43:10.0000] <annevk>
Ms2ger: no

[01:43:41.0000] <annevk>
Ms2ger: encoding library is expects scalar values

[01:43:46.0000] <annevk>
s/is//

[01:44:02.0000] <annevk>
MikeSmith: oh

[01:44:05.0000] <slightlyoff>
MikeSmith: had it been available at the time, we'd have used WICG instead of my private github repo

[01:44:10.0000] <slightlyoff>
and we are using the W3C process

[01:44:16.0000] <MikeSmith>
ok

[01:45:32.0000] <Ms2ger>
I suspected as much

[01:45:33.0000] <Ms2ger>
https://github.com/whatwg/html/issues/970

[04:57:43.0000] <annevk>
mounir: any plans to update the Permissions API?

[04:58:01.0000] <annevk>
mounir: and maybe provide a PR for Notifications API so they're actually linked and use the same permission store?

[04:58:25.0000] <annevk>
mounir: none of the issues I raised a year ago have moved much it seems, that's not very encouraging

[04:58:47.0000] <annevk>
mounir: I'm now trying to fix some outstanding issues with Storage, and the Permissions API spec is still in a broken state

[05:04:54.0000] <annevk>
TabAtkins: Shepherd should start indexing https://w3c.github.io/permissions/

[05:32:37.0000] <JakeA>
annevk: I guess storage also includes the service worker registration?

[05:47:17.0000] <mounir>
annevk: jyasskin has been helping recently, I think he might have a few PR you would be interested in

[05:47:44.0000] <mounir>
annevk: sorry for the slow progress, it's a side project

[05:59:11.0000] <annevk>
JakeA: yeah it must

[05:59:49.0000] <annevk>
JakeA: we need to make sure all storage stuff like that is layered on top of this, so that box operations affect all of them at once

[06:00:04.0000] <annevk>
JakeA: and we need to also make it clear which things are distinct

[06:00:17.0000] <annevk>
JakeA: e.g., permissions and credentials are clearly stored separately

[06:01:34.0000] <JakeA>
Hadn't considered that about permissions, but yeah, makes sense

[06:32:18.0000] <annevk>
JakeA: mentioned them in https://storage.spec.whatwg.org/#infrastructure

[06:59:51.0000] <JakeA>
perfect, cheers!

[07:03:43.0000] <annevk>
I wonder if an email client can detect an out-of-office email and forward those to trash

[07:04:25.0000] <annevk>
E.g., I have a hard time caring mkwst will not reply to my email today, even though he just replied to the same thread

[07:04:38.0000] <mkwst>
Hrm?

[07:04:50.0000] <annevk>
mkwst: I got an autoresponder from you

[07:05:02.0000] <mkwst>
Hrm. That should be off. I got back in this morning.

[07:05:39.0000] <mkwst>
Off now. Sorry. Off by one. :/

[07:06:02.0000] <mkwst>
What email do you have a hard time caring about?

[07:06:16.0000] <mkwst>
Sorry. I've been out for a week, and I'm not at all on top of things.

[07:06:35.0000] <mkwst>
(If you're missing something from me, tell me. :) )

[07:07:21.0000] <annevk>
mkwst: just your autoresponder emails, I care about the others

[07:07:58.0000] <mkwst>
You don't have a deep desire to know whether or not I'm on vacation?

[07:08:07.0000] <mkwst>
I thought that was a universal human need.

[07:08:24.0000] <annevk>
mkwst: that explains why you work for Google

[07:08:47.0000] <mkwst>
No, Google wants to know whether _you_ are on vacation.

[07:10:33.0000] <jgraham>
Eventually gmail will just automatically provide autoresponder emails like "Sorry, mkwst is by a pool in Vegas right now. He lost $10,000 this morning and so won't be responding to your email soon."

[07:12:11.0000] <mkwst>
Delighting users, one autoresponder at a time.

[07:30:20.0000] <TabAtkins>
annevk: ReSpec'd, so all the definitions are worthless.  Every one of them will be a "dfn"-type definition, unexported.  And they duplicate several terms from other specs (luckily those are unexported too).

[07:37:58.0000] <annevk>
TabAtkins: hmm, maybe jyasskin can convert it to bikeshed

[07:39:37.0000] <jyasskin>
annevk: I won't override the editors on that, but I am volunteering to help edit Permissions, in which case converting to Bikeshed is the price.

[07:41:03.0000] <annevk>
jyasskin: since "the editors" haven't been doing much for a year I think you should be fine

[07:41:26.0000] <jyasskin>
annevk: https://github.com/w3c/permissions/pull/66 has the basics for extending permissions from other specs. I'm just assuming the "partial enum" problem is solved.

[07:42:02.0000] <annevk>
jyasskin: I don't care much about that, I actually think it's better if permissions is the registry so it keeps a coherent view on all permissions

[07:42:48.0000] <annevk>
jyasskin: what I mostly care about is primitives to hook into around the permission storage that actually work, i.e., that take a permission name and an origin, and things like that

[07:43:32.0000] <jyasskin>
https://rawgit.com/jyasskin/permissions/allow-choosers/index.html#dfn-get-a-permission-storage-identifier takes a name and a settings object.

[07:45:19.0000] <annevk>
jyasskin: that looks a little better

[07:45:45.0000] <annevk>
jyasskin: are you actively working on this? If that's the case I'm happy to review tomorrow

[07:45:58.0000] <jyasskin>
I'm looking at this as an incremental improvement. There's a bunch left to fix, but I can't tackle it all in one PR.

[07:46:02.0000] <jyasskin>
Yes.

[07:46:16.0000] <annevk>
Yeah understood

[07:47:29.0000] <jyasskin>
What do you suggest I do to get commit access? Mail you, mounir, marcos, and Dom?

[07:48:03.0000] <annevk>
jyasskin: MikeSmith can usually arrange that

[07:48:24.0000] <annevk>
jyasskin: no need to email me, I don't have power in /w3c

[07:48:34.0000] <jyasskin>
I'd mail you for the endorsement. ;)

[07:48:39.0000] <annevk>
hah

[08:22:56.0000] <zcorpan>
i might be able to give you commit access

[08:28:39.0000] <TabAtkins>
jyasskin: It doesn't need to be fully Bikeshedded, just have its definitions upgraded.  But Bikeshedding is always nice, of course. ^_^

[08:29:01.0000] <jyasskin>
Bikeshedding makes everything so much easier.

[08:30:24.0000] <annevk>
Including reviewing the document, ReSpec still FOUCs

[08:31:02.0000] <MikeSmith>
jyasskin: made you a pusher

[08:31:13.0000] <jyasskin>
MikeSmith: Thanks!

[08:31:23.0000] <MikeSmith>
cheers

[08:47:51.0000] <jyasskin>
TabAtkins: You don't have any tidy-like tool for .bs files, do you?

[08:48:01.0000] <TabAtkins>
No, but I've been wanting to design one.

[08:48:11.0000] <TabAtkins>
Feel free to open an issue on me with some suggestions for things you want linted/formatted.

[09:48:55.0000] <annevk>
jyasskin: btw, I think ideally we have fairly simple hooks here

[09:49:45.0000] <annevk>
jyasskin: e.g. "If permission for "notification" and /notication/'s origin is "granted", ..." with "permission" being something you define

[09:50:04.0000] <annevk>
(sorry about the double " quotes)

[09:50:20.0000] <jyasskin>
"permission" being something the notification API defines, or the permissions API?

[09:50:32.0000] <annevk>
jyasskin: the permissions API

[09:51:02.0000] <annevk>
jyasskin: ideally the Notifications API no longer has to define "permission" at all, since it can defer to the Permissions store for that now

[09:51:45.0000] <jyasskin>
annevk: We have enough kinds of permission, and enough data associated with permissions, that I'm not sure there can be a single unified definition. The ones that are simply boolean should definitely be able to just reference Permissions, but others are more complex.

[09:52:04.0000] <annevk>
jyasskin: yeah, I guess this would only work for the simple ones

[09:52:28.0000] <annevk>
jyasskin: and for the others you'd have to do something complex, although I'm still not entirely convinced more complex ones are a good idea

[09:53:35.0000] <jyasskin>
annevk: My example here is Bluetooth, of course. If we want it to fit into the API, we need to be able to store a list of devices, and be able to query that list.

[09:53:56.0000] <jyasskin>
It looks like media was already going that direction in the spec, but without any rigor.

[09:54:21.0000] <annevk>
too many editors that don't care about design

[09:55:03.0000] <jyasskin>
Eh, whatever the cause, we have to look for the right design now.

[09:55:27.0000] <annevk>
or maybe they don't care about details? It's not entirely clear to me what's missing, but there's certainly lots of messes being created at all times, and few bineg solved

[09:55:30.0000] <annevk>
being*

[09:56:32.0000] <annevk>
jyasskin: but yeah, if we could have a very basic get/set framework for boolean permissions that'd be great

[09:57:05.0000] <annevk>
jyasskin: although maybe I should first review your work, since it seemed you had some interesting things around cleanup and such too

[09:57:36.0000] <jyasskin>
Mhmm. Right now, I have https://rawgit.com/jyasskin/permissions/allow-choosers/index.html#geolocation and friends explicitly specify the whole permission interface, but it'd be easy to define a "boolean permission" shorthand for them. I was waiting to see how many there actually were.

[09:58:21.0000] <annevk>
There's also some potential disagreement

[09:58:39.0000] <annevk>
E.g. I think "persistentstorage" is boolean, but I don't think everyone at Google agrees

[10:13:12.0000] <jyasskin>
annevk: This inclines me more toward letting individual specs define their own permissions, instead of trying to centralize those debates through the Permissions editor.

[10:13:59.0000] <jyasskin>
Having the enum centrally, and then link to the definitions in each spec, could work well.

[11:05:38.0000] <annevk>
Yeah, maybe

[11:05:56.0000] <annevk>
Depends a bit on the particulars I suppose

[12:38:12.0000] <annevk>
TabAtkins: it seems that lacking a newline after <pre><code class="lang-javascript"> actually influences parsing: https://storage.spec.whatwg.org/#introduction

[12:38:23.0000] <annevk>
TabAtkins: if I add a newline locally the wrapping is correct

[12:38:57.0000] <TabAtkins>
It absolutely does. Bikeshed is very opinionated about the structure of your <pre>, so it can tell in a reasonable way what you "indent" is, and correct it in the output HTML.

[12:39:01.0000] <annevk>
(with the if statement appearing on the next line, and "navigator.storage.persistent()," too)

[12:39:21.0000] <annevk>
That seems very wrong

[12:39:24.0000] <TabAtkins>
That way you don't have to put your <pre> contents flush with the left edge, messing up your HTML indentation, like you have to do in normal HTML.

[12:39:24.0000] <annevk>
Oh well

[12:40:16.0000] <TabAtkins>
It's not wrong. It's a particular choice to make sure your input documents look good; without it, your input documents contain ugly formatting hacks that aren't necessary *anywhere else* in HTML.

[12:40:30.0000] <annevk>
I wish bikeshed would use custom elements for this kind of stuff

[12:40:34.0000] <TabAtkins>
You either lack indentation, or use funky comment hacks, both of which are terrible.

[12:40:43.0000] <annevk>
Changing the meaning of existing HTML elements is super confusing

[12:41:05.0000] <TabAtkins>
Perhaps easier to put yourself in the mindset that Bikeshed's input format is not, technically, HTML, but a language close to it. ^_^

[12:41:52.0000] <TabAtkins>
(People are generally *happy* when they run into this bug, because as soon as they learn the *right* thing, they can start formatting their <pre> contents *naturally* instead of the hacky bullshit way they were doing so previously.)

[12:42:05.0000] <TabAtkins>
(This is something I should lint for, tho.)

[12:42:25.0000] <jyasskin>
More, happy once we've gotten used to it and realize the benefits. We're all grumpy when we hit it the first time. I think I filed a bug.

[12:42:36.0000] <annevk>
All I want is a maintained Anolis with automatic xref...

[12:42:55.0000] <annevk>
I don't really have a need for all this magic that bites me every time

[12:43:48.0000] <annevk>
But it's easy enough to get used to adding a newline

[12:44:52.0000] <TabAtkins>
I really am genuinely sorry you got really used to the mannerisms of a preprocessor nobody's willing to use anymore.

[12:46:04.0000] <annevk>
Well the thing is, Anolis is basically HTML, no magic

[12:46:17.0000] <annevk>
And Wattsi is quite similar

[12:46:35.0000] <TabAtkins>
Most users are new to this stuff, so it's easier for them to learn. Less things to unlearn.

[12:46:35.0000] <TabAtkins>
I'm def sympathetic.

[12:46:35.0000] <TabAtkins>
(Your willingness to work with Anolis-style xrefs was truly heroic, they're a *ton* of typing.)

[12:46:42.0000] <annevk>
It's mostly bikeshed I think that parses Markdown before HTML and such

[12:47:11.0000] <annevk>
Typing isn't really the work though when writing specs

[12:48:14.0000] <jyasskin>
It's not really the work in programming either, but we still look for concise languages.

[12:49:03.0000] <annevk>
True, I think actually ecmarkup might be even better than bikeshed, but it probably lacks cross-spec cross-references

[12:49:20.0000] <TabAtkins>
Like, typing isn't the WORK work, but it's still a lot of work, and minimizing that is ideal.

[12:49:51.0000] <TabAtkins>
I think Domenic passes things through both Bikeshed *and* ecmarkup? I've got plans for integrate ecmarkup's shorthands when I have some downtime.

[12:50:01.0000] <annevk>
And I think we want something ecmarkup like long term given that's what ECMAScript is in and everything else descends from that, in a way

[12:50:26.0000] <annevk>
TabAtkins: yeah, Domenic has some special setup for Streams

[12:50:36.0000] <annevk>
Maybe the future is there somewhere

[12:50:59.0000] <TabAtkins>
"All specs should be like ECMAScript" is something that very few people would be able to get behind, I think. The precision is nice, but it's *impossible* to read unless you're deeply skilled in spec-ese.

[12:51:25.0000] <annevk>
And yeah, definitely want to explore this a bit too at some point, maybe after shadow DOM / custom elements

[12:51:26.0000] <TabAtkins>
But anyway, nothing good about ECMAScript is related to the processor.

[12:52:17.0000] <TabAtkins>
annevk: All I care about is that any new processors people work on, interoperate in their definitions model.

[12:52:18.0000] <annevk>
TabAtkins: 1) I think ECMAScript is getting better 2) We'd still have IDL to help us out, just in a more ECMAScript-y way

[12:52:43.0000] <annevk>
TabAtkins: yeah, should maybe see if we can make some easy wins with Wattsi with respect to that

[12:52:52.0000] <TabAtkins>
https://github.com/tabatkins/bikeshed/blob/master/docs/dfn-contract.md is the dfn contract

[12:53:06.0000] <annevk>
Anyway, bedtime, ttyl

[12:53:12.0000] <jyasskin>
TabAtkins: Is there a spec for the API to query the dfn database?

[12:53:25.0000] <TabAtkins>
bikeshed refs --help

[12:54:14.0000] <jyasskin>
Hm, for another tool to use? I guess that's https://api.csswg.org/shepherd/

[12:54:42.0000] <TabAtkins>
Ah, tool-usable.

[12:55:21.0000] <jyasskin>
My thought is that ecmarkup or Anolis should be able to query the same database.

[12:55:23.0000] <TabAtkins>
Yeah, that's it.  Note that Bikeshed does a *bunch* of post-processing on that data.

[12:55:40.0000] <TabAtkins>
jyasskin: Yeah, everyone sharing the same db is what we want.

[12:56:05.0000] <TabAtkins>
/me is still considering taking over the spidering in an independent project, a la SpecRef, so people can see it more easily and help out.

[12:58:02.0000] <TabAtkins>
Off to lunch, bbiab if this discussion continues.

[13:03:51.0000] <Domenic>
FWIW I'm currently (between TC39 speeches) trying to make Streams use more Bikeshed features. We'll see how well that integrates with the ecmarkup parts...

[13:04:35.0000] <Domenic>
As of this morning it basically only used <dfn>s and <a>s to link between them. Now trying to mark up classes/constructors/methods/properties and {{link}} to them and such.

[13:58:46.0000] <zcorpan>
I use f.lux which makes the screen emit less blue light in the evenings, which is nice but it also makes me kinda colour blind: links in whatwg specs look exactly like the surrounding text

[14:00:29.0000] <zcorpan>
that seems like something we should fix. not just for me but also for people who are actually color blind

[14:35:19.0000] <Domenic>
TabAtkins: if I add {{EventTarget}} in an example section I get a normative reference to DOM. How can I make it non-normative?

[14:36:32.0000] <TabAtkins>
Domenic: Hm, if it has a parent with class=note or class=example, it should get marked as non-normative.

[14:36:58.0000] <Domenic>
TabAtkins: it doesn't though; it has a nearby <p><em>This section is non-normative.</em></p>

[14:37:25.0000] <TabAtkins>
Ah, so I"m not looking for that yet. I'm open to increasing the set of things that it looks for, as long as we can do so safely.

[14:37:52.0000] <TabAtkins>
Would you be opposed to adding a class to the heading, for example?

[14:38:21.0000] <Domenic>
TabAtkins: yeah that'd be OK... I'd also accept <a idl nonnormative> or something

[14:38:25.0000] <TabAtkins>
(The warnings you mention aren't safe; it's not clear how large their scope is in a machine-detectable way.)

[14:38:48.0000] <TabAtkins>
Yeah, I can just expand it to look for a class="non-normative" on it or an ancestor, if you want.

[14:39:38.0000] <Domenic>
👍

[14:39:55.0000] <Domenic>
I'll file an issue?

[14:40:04.0000] <TabAtkins>
No need, committing now.

[14:40:09.0000] <Domenic>
\o/

[14:40:34.0000] <Domenic>
TabAtkins: also is there a way to turn off ignored vars checking? I couldn't find it in the docs.

[14:40:48.0000] <TabAtkins>
Entirely? Not right now, no.

[14:56:12.0000] <jochen__>
does somebody know why the payments API uses "objects that can be passed through JSON.parse(JSON.stringify()) without loss of data instead of SerializedScriptValue?

[15:02:57.0000] <TabAtkins>
Lack of knowledge?

[15:03:56.0000] <Mek>
I don't think SerializedScriptValue is a thing in specs. You probably meant structured cloneable?

[15:04:23.0000] <Mek>
but I was wondering the same thing, and guessed that it might be because that data gets passed to possibly external native code, which is easier with json rather than arbitrary structured cloneable data

[15:04:53.0000] <Mek>
but the spec could still allow more, since the various payment providers will have to define their own valid subset of data anyway

[15:08:58.0000] <jochen__>
well, it's a thing in IDL, isn't it?

[15:09:46.0000] <Mek>
I don't think so

[15:09:56.0000] <jochen__>
mhm

[15:10:31.0000] <jochen__>
so whatever it is in spec-speak, afaik all browsers can serialize the history.state object to disk

[15:10:37.0000] <Mek>
at least HTML uses "any" in IDL and "StructuredCloneWithTransfer" for postMessage

[15:10:55.0000] <jochen__>
and that's a SerializedScriptValue in Blink & WK

[15:11:23.0000] <jochen__>
ok, fair enough

[15:11:24.0000] <Mek>
same for history.state

[15:12:15.0000] <Mek>
but yes, I agree that payment request should use any/structured cloneable in the spec (although the implementation in blink will likely still not be able to use SerializedScriptValue due to implementation details of SerializedScriptValue)

[15:20:50.0000] <Domenic>
It depends on if they ever want to e.g. send something over HTTP

[15:20:57.0000] <Domenic>
In which case structured-cloneable doesn't make sense

[15:25:59.0000] <jochen__>
dunno

[15:26:15.0000] <jochen__>
if you want a wire format, you should specify a wire format

[15:27:07.0000] <Domenic>
JSON seems good

[15:27:57.0000] <jochen__>
i'm not saying it's not

[15:28:27.0000] <jochen__>
it's just odd that the wire format is defined implicitly by messing with the IDL

[15:53:18.0000] <Domenic>
TabAtkins: given https://github.com/whatwg/streams/blob/better-spec-hygeine/index.bs#L34-L43 I cannot figure out why %Uint8Array% and friends appear in the index at https://streams.spec.whatwg.org/commit-snapshots/62d8cae22d91df2626c50ae3238e077d6b583dad/#index-defined-elsewhere, but WebSocket does not?

[15:58:40.0000] <Domenic>
Hmm structured clone also isn't showing up

[16:01:41.0000] <TabAtkins>
Domenic: That... is a good question.

[16:01:44.0000] <TabAtkins>
Log an issue?

[16:01:59.0000] <Domenic>
yeah

[16:05:18.0000] <TabAtkins>
Domenic: Oh, those anchors don't have a "spec" declared.

[16:05:42.0000] <Domenic>
TabAtkins: hmmm is this because of the conflicting definitions from different specs things?

[16:05:46.0000] <Domenic>
i.e. why does ES not have this problem

[16:05:58.0000] <TabAtkins>
Because you specified "spec" for those anchors.

[16:06:07.0000] <TabAtkins>
Line 37

[16:06:17.0000] <Domenic>
TabAtkins: oh, duh, ok thanks!

[16:06:39.0000] <TabAtkins>
There's still something weird/unusable here.  I'll need to figure out what needs doing.