2017-03-01
[16:04:59.0000] <Domenic>
Hmm yeah

[16:05:09.0000] <Domenic>
Not sure how this fits into the Web IDL type system

[16:05:15.0000] <Domenic>
Since it doesn't make much sense as a return type

[16:26:57.0000] <TabAtkins>
Well, it can output as a Map as a return value.

[16:27:09.0000] <TabAtkins>
Same as sequence<> outputs as an Array (but can be lots of things as an argument value)

[16:27:15.0000] <Domenic>
Hmm not bad

[17:01:02.0000] <Domenic>
Wow 88.6% of pages use UTF-8?? https://w3techs.com/technologies/overview/character_encoding/all

[17:01:06.0000] <Domenic>
I didn't know the world was such a happy place

[17:09:43.0000] <Domenic>
https://en.wikipedia.org/wiki/UTF-8#/media/File:Utf8webgrowth.svg

[17:16:35.0000] <Domenic>
I wonder why https://en.wikipedia.org/wiki/UTF-8#WTF-8 doesn't mention https://simonsapin.github.io/wtf-8/

[17:19:53.0000] <Domenic>
http://people.ds.cam.ac.uk/fanf2/hermes/doc/qsmtp/draft-fanf-wtf8.html is funny

[19:19:41.0000] <Krinkle>
Curious if there's any recommended way of dealing with localStorage key eviction, in a way that scales reasonably and performs well on mobile. https://github.com/whatwg/storage/issues/11#issuecomment-283233411 / https://phabricator.wikimedia.org/T121646#3063515

[22:42:59.0000] <yoav>
annevk: Finally getting back to https://github.com/whatwg/fetch/pull/442/files#r96880945

[22:46:02.0000] <yoav>
If I properly understand your suggestion there, you'd prefer to get rid of all changes in current PR, create the concept of "potential destination", have preload use that, and just translate is to destination before preload triggers a fetch

[22:46:06.0000] <yoav>
is that correct?

[00:05:37.0000] <JakeA>
MikeSmith: the outline stuff in the html5 checker… does it miss section roots because the generated outline doesn't provide a link from the parent to child roots?

[00:09:54.0000] <MikeSmith>
JakeA: no it doesn’t show the headings for the sectioning roots because that is the required result of following the outline algorithm as specified

[00:10:29.0000] <MikeSmith>
the spec says nothing about generating separate outlines for the sectioning roots and then linking them together

[00:11:45.0000] <MikeSmith>
the algorithm if applied to a document builds only a single outline for the document, which drops any headings for the sectioning roots

[00:12:17.0000] <MikeSmith>
all the existing implementations of the outline algorithm have followed the spec on this

[00:12:25.0000] <MikeSmith>
e.g., h5o and gsnedders outliner

[00:14:07.0000] <MikeSmith>
I guess it could be argued that the it’s assumed we’re supposed to re-run the algorithm on each sectioning root we run into and .. somehow store a separate object for each and then somehow link them together

[00:14:33.0000] <MikeSmith>
but that’s not what the actual normative spec text says to do

[00:16:25.0000] <JakeA>
MikeSmith: this sounds like *looks into camera* the root of the issue

[00:16:35.0000] <JakeA>
Trying to get confirmation from Hixie

[00:26:25.0000] <MikeSmith>
it’s cool when you look into the camera like that

[07:04:25.0000] <tobie>
JakeA: I'm working on motion sensors right now. Some of the use cases sound like great candidates for background events.

[07:05:00.0000] <tobie>
JakeA: was curious if you had data on how often SW are woken-up in practice

[07:05:12.0000] <tobie>
JakeA: + battery cost of doing so

[07:05:33.0000] <tobie>
JakeA: use cases are e.g. indoor navigation using sensor data

[07:06:18.0000] <JakeA>
tobie: I think the battery cost is generally pretty high, because it involves booting the browser up. I don't have data though, because no two cases are alike

[07:06:40.0000] <JakeA>
tobie: But I know that the Physical Web folks couldn't wake the SW up per beacon

[07:07:23.0000] <annevk>
So I was thinking that if we added integrity to service workers we could maybe allow them cross-origin, but that still wouldn't protect against an XSS-installed service worker

[07:07:54.0000] <JakeA>
That's the main reason we haven't allowed them

[07:08:04.0000] <annevk>
So what you really need is some kind of nonce+integrity or integrity declared through HTTP headers

[07:08:40.0000] <annevk>
If integrity is declared through HTTP, you should be safe from XSS

[07:08:53.0000] <annevk>
I'm not sure what the latest on that is exactly though

[07:09:51.0000] <annevk>
(Also, I'm just brainstorming a bit here, I haven't seen many requests or indication this is a priority.)

[07:09:55.0000] <tobie>
JakeA: so even 1/minute would be too much

[07:10:05.0000] <JakeA>
tobie: oh wow yes

[07:11:19.0000] <tobie>
JakeA: need to balance size of data collected too.

[07:11:56.0000] <JakeA>
tobie: I think the main cost is booting up the browser and potentially the radio too

[07:21:59.0000] <tobie>
JakeA: sounds like I need to revise my plans, than. :(

[07:22:07.0000] <tobie>
s/than/then/

[07:22:39.0000] <tobie>
JakeA: thanks!

[07:37:16.0000] <annevk>
jgraham: Ms2ger: here's an alternative WPT review plan: I land my own PRs and file browser bugs on the failures which will lead to review

[07:38:05.0000] <annevk>
jgraham: Ms2ger: I also think we should maybe prune OWNER files where folks haven't been reviewing changes in a while as the current system is more like a PING file since nobody can be hold accountable

[07:40:03.0000] <annevk>
tobie: I think for mobile sensors you really want something like Apple's M chip series

[07:40:44.0000] <annevk>
tobie: that just store a bunch of the data and then expose it to the app at the point the user might do something with it

[07:41:05.0000] <annevk>
tobie: depends a bit on the sensor too of course

[07:41:20.0000] <tobie>
annevk: the owner files were bootstrapped from the list of committers to that directory.

[07:41:36.0000] <tobie>
annevk: they were *mean't* to be edited and pruned.

[07:41:43.0000] <tobie>
meant

[07:41:56.0000] <tobie>
/me can't spell todya

[07:42:43.0000] <tobie>
annevk: yes, I guess. I was mostly wondering if there was a way to bridge different use cases through SW

[07:44:42.0000] <gsnedders>
annevk: there are definitely people who want to be in a PING file though

[07:45:04.0000] <gsnedders>
annevk: one option is we simply introduce two separate files and update wpt-pr-bot

[07:45:41.0000] <tobie>
annevk: e.g. storing motion data for mapping out the number of steps on a run once you're back from it, vs near real-time indoor positioning on map using sensors.

[07:45:46.0000] <annevk>
gsnedders: I think a reasonable solution would be to move all OWNERS to PING and only once we have an actual OWNER add them there

[07:46:27.0000] <tobie>
gsnedders: add categories to owners.

[07:47:39.0000] <tobie>
gsnedders: rename all the files if you want to.

[07:47:54.0000] <tobie>
gsnedders: but dealing with more than one file seems tedious

[07:48:01.0000] <gsnedders>
tobie: yeah, on the whole I agree

[07:52:27.0000] <Ms2ger>
OWNERS was intended to mean PING, really

[07:53:06.0000] <Ms2ger>
I don't think allowing particular people to land without any review is a good idea

[07:53:41.0000] <gsnedders>
landing without review also ties into the discussions about how to deal with specs that are still incubating and moving fast

[07:57:13.0000] <annevk>
Ms2ger: I didn't say it's without review, it's just that the review is delayed

[07:57:46.0000] <annevk>
Ms2ger: because currently there's no review and that means everything is stalled

[07:58:51.0000] <annevk>
And the OWNERS/PING thing was unrelated to this review thing, that was more about making sure we actually know who are responsible (or whether we lack someone responsible)

[07:59:34.0000] <annevk>
You need some accountability

[08:00:03.0000] <annevk>
We could also do OWNERS / PEERS

[08:02:42.0000] <Ms2ger>
The situation we have right now is that nobody is responsible

[08:03:10.0000] <Ms2ger>
That's a problem of resource allocation, not files

[08:03:41.0000] <annevk>
Well, making that transparent seems like a good first step

[08:04:07.0000] <annevk>
And I actually want to be responsible for URL/CORS/XHR/Fetch/Encoding

[08:05:13.0000] <annevk>
And have made lots of changes over the past couple weeks to get those more into shape as you may or may not have noticed

[08:05:25.0000] <annevk>
It's based on that experience that I'm here suggesting changes

[08:05:44.0000] <annevk>
Being dismissive of them without really suggesting something else is not helping

[08:07:21.0000] <jgraham>
annevk: But I think the problem is that no one believes that review-later will cause review to happen

[08:07:43.0000] <annevk>
I do?

[08:07:50.0000] <annevk>
Implementations will have to fix their bugs after all

[08:07:58.0000] <annevk>
Or do you think they won't ever fix their bugs?

[08:08:07.0000] <annevk>
At that point you've lost

[08:08:33.0000] <gsnedders>
annevk: what vendor makes a general effort to fix new failing tests in wpt? AFAIK, none seriously do.

[08:08:51.0000] <annevk>
Lots do when bugs are filed

[08:08:59.0000] <annevk>
Firefox has, WebKit has, Edge has, Chrome has

[08:09:07.0000] <annevk>
I know because I've been doing this for a while

[08:09:12.0000] <gsnedders>
so we need a system that when a new failing test is added automatically file bugs?

[08:09:21.0000] <annevk>
No, I just file the bugs

[08:09:25.0000] <annevk>
As I said earlier...

[08:09:58.0000] <gsnedders>
no, I mean in general case of how we get people to care about failing tests

[08:10:09.0000] <annevk>
They already do

[08:10:51.0000] <gsnedders>
do they? when Gecko, Blink sync up to the latest web-platform-tests, they add expectations files to ignore any failures but don't analyse or file bugs for them.

[08:11:49.0000] <annevk>
That's their current system, but if you talk to the engineers they do want to fix those failures

[08:11:54.0000] <annevk>
And if you file bugs they do fix them

[08:12:04.0000] <annevk>
Again, I have some experience with this

[08:12:53.0000] <gsnedders>
the problem is I don't think it's practical to get every contributor to wpt to be running tests in all browsers and filing bugs

[08:13:27.0000] <annevk>
Geez

[08:13:34.0000] <annevk>
So require review for those contributors

[08:14:40.0000] <annevk>
Can we talk a bit more constructively about this perhaps?

[08:16:19.0000] <gsnedders>
The problem is we need a way that doesn't rely on individual contributors because otherwise we'll have failures slip through. That's my point.

[08:17:03.0000] <gsnedders>
And the problem is a hard one unless there's someone who's job it is is to analyse all incoming failures.

[08:17:15.0000] <jgraham>
annevk: So I'm feeling too ill to have an argument :) But I think my issue is different from gsnedders. I don't doubt that often you can find someone to at least look at failing tests (and you, specifically, have the social capital to make that process work resaonably often). But no one is going to look at passing tests (especially if you check in a file of tests that only pass). And it seems weird that you are happy to require review for spec chang

[08:17:31.0000] <jgraham>
(OK, where did that get cut off?)

[08:17:39.0000] <gsnedders>
"review for spec change"

[08:17:53.0000] <jgraham>
And it seems weird that you are happy to  require review for spec changes but requiring equivalent review for tests is too hard.  Can't you require the same reviewer to look at both?

[08:18:10.0000] <annevk>
jgraham: this is cleanup of existing tests

[08:18:23.0000] <annevk>
jgraham: or adding coverage

[08:19:13.0000] <annevk>
jgraham: and I do actually review passing tests every now and then too

[08:19:30.0000] <annevk>
jgraham: in particular when they need to be revised or we add new features or some such

[08:19:46.0000] <jgraham>
annevk: That you in particular are an angel (per diveintomark) is not in question

[08:19:55.0000] <annevk>
gsnedders: sure, the system is not perfect, but the current system basically makes me stop contributing

[08:20:00.0000] <annevk>
gsnedders: which seems worse

[08:20:40.0000] <jgraham>
annevk: So the hacky solution is to commit to m-c and ask for review from people at Mozilla because they clearly have a job description that involves doing those reviews

[08:21:36.0000] <jgraham>
(and when I say "hacky" it's an explicit design goal to leverage that fact)

[08:22:25.0000] <jgraham>
The less hacky solution seems to be to get some individuals to agree that reviewing your cleanup tests is also part of their job. It still seems strange that you can find that group for spec changes but not for test changes

[08:24:26.0000] <annevk>
Sure, I can probably get them rubberstamped

[08:24:51.0000] <annevk>
The system not pretending OWNERS will review the test as they actually don't might help with that

[08:25:20.0000] <annevk>
So I don't wait several days for them and then wait several days for whatever victim I can find

[08:26:42.0000] <jgraham>
Sure, if you want some technical fix to not imply that OWNERS actually feel a sense of responsibility then I'm happy with that

[08:52:45.0000] <tobie>
annevk: fwiw: the current review process (which is to allow one r+ either in wpt or in another public system) is something I fought for when I was at FB/W3C as a way to simplify the previous process which required someone *from a different company* to approve a contribution.

[08:53:25.0000] <tobie>
annevk: there is nothing that prevents us from modifying that process if it turns out it's not optimum

[08:53:56.0000] <tobie>
annevk: I don't think there's a formal process for gathering consensus around that.

[08:54:39.0000] <tobie>
annevk: I'd argue filing a bug/pr on the docs where the process is specified + mailing the testing-infra@ should be enough

[08:55:53.0000] <tobie>
annevk: possible work arounds could include: allow people with owner status to r+ their own changes,

[08:56:17.0000] <tobie>
have a lits of special contributors which can r+ their own changes

[08:56:35.0000] <tobie>
maybe have a (light) process to get someone on that list.

[08:57:06.0000] <tobie>
annevk: this is not rocket science, and whatever process is in place should be there to serve the goals of the project

[08:57:12.0000] <tobie>
annevk: not hinder them

[09:36:34.0000] <annevk>
tobie: thanks for the suggestions, I guess I need to think a bit more about what exactly needs to change beyond changing OWNERS

[09:58:45.0000] <tobie>
annevk: thanks for the reference to Apple M-series, btw. I knew these things existed, but didn't know what they were called.

[09:59:01.0000] <tobie>
annevk: now I have a nice Wikipedia article to point people to.


2017-03-02
[16:09:54.0000] <domfarolino>
I noticed in HTML spec there is a section dedicated to custom elements, while there is also a full on custom elements spec (https://www.w3.org/TR/custom-elements/). Both seem to contain relatively the same info

[16:10:14.0000] <domfarolino>
Is there a reason whatwg does not host a separate custom elements spec (written by whatwg member ddenicola) and just reference it via HTML spec?

[16:12:54.0000] <domfarolino>
Thought it was kinda odd that the entire CE spec sorta existed in HTML spec, without being pulled out in a whatwg repo (though it is pulled out in w3, and written by whatwg member)

[16:17:12.0000] <MikeSmith>
domfarolino: https://dom.spec.whatwg.org/ also defines parts of the custom-elements requirements

[16:19:24.0000] <MikeSmith>
the reason for integrating the requirements into the HTML and DOM specs is that they have always been monkey patches and the assumption all along from the people actually working on defining the requirements is that the requirements would eventually be folded back into the HTML and DOM specs and the monkey patching spec would no longer be needed

[16:20:47.0000] <MikeSmith>
in other words the reason for not pulling the requirements (back) out into a separate spec is that they don’t rightly belong in a separate spec, they belong in the HTML spec and the DOM spec

[16:22:14.0000] <MikeSmith>
the requirements necessitate, e.g., adding particular steps to particular existing algorithms in the HTML and DOM specs

[16:22:33.0000] <domfarolino>
MikeSmith ok that makes sense that it is sort of a subset of those two specs

[16:23:03.0000] <MikeSmith>
yeah

[16:23:07.0000] <domfarolino>
MikeSmith: is there a reason then that for some reason it has been pulled out into its own spec but just on w3c territory?

[16:23:45.0000] <domfarolino>
regardless what you said makes sense thanks

[16:24:04.0000] <MikeSmith>
the reason for what you just asked is .. complicated

[16:24:23.0000] <MikeSmith>
and I’m not the right person to comment on that

[16:24:23.0000] <domfarolino>
I see...policial I assume?

[16:24:30.0000] <domfarolino>
gotcha

[16:24:36.0000] <domfarolino>
political*

[16:27:16.0000] <annevk>
domfarolino: yes

[17:34:24.0000] <domfarolino>
anybody online willing to answer a quick Q I have regarding the algos pertaining to script modules in the HTML spec?

[17:41:04.0000] <annevk>
domfarolino: best just to ask

[17:44:01.0000] <domfarolino>
annevk: thanks. I came across the algorithm for determining a script's "uninstantiated inclusive descendant module scripts" (https://html.spec.whatwg.org/multipage/webappapis.html#uninstantiated-inclusive-descendant-module-scripts). it is a basic DFS (as noted in script), however I was wondering if step 4 > 2 is a bit redundant?

[17:44:37.0000] <domfarolino>
In other words, why are we checking `current`'s existence in BOTH `stack` and `inclusive descendants` as opposed to just `inclusive...`?

[17:46:58.0000] <domfarolino>
I could be missing something, but wouldn't it work the same by just checking existence in `inclusive descendants`? Just wondering if I'm missing some nuance with how a script's deps work

[17:48:20.0000] <annevk>
domfarolino: it matters for ordering at least

[17:48:28.0000] <domfarolino>
Thats what I first thought

[17:48:36.0000] <annevk>
domfarolino: not sure how stack is determined though

[17:48:57.0000] <domfarolino>
I then saw the note at the bottom saying something to the effect of "as long as it returns a set, whose order does not matter"

[17:50:46.0000] <annevk>
Hmm best to wait for Domenic then or maybe raise an issue

[17:51:07.0000] <domfarolino>
Ok thanks for the insight...just curious :)

[10:31:11.0000] <smaug>
anyone familiar with WebVR?

[10:33:18.0000] <KiChjang>
smaug, which aspects of it?

[10:33:32.0000] <smaug>
when is vrdisplaypresentchange dispatched?

[10:33:55.0000] <smaug>
(both 1.1 and editor's draft are super high level specs)

[10:34:11.0000] <KiChjang>
uh, not sure, but i know of someone who implemented this

[10:34:54.0000] <smaug>
yeah, I know too at Mozilla but he isn't online atm

[10:35:22.0000] <KiChjang>
are you thinking of mortimer?

[10:37:46.0000] <smaug>
I'm thinking kip

[10:40:53.0000] <KiChjang>
smaug, the tests here may shed some light: https://github.com/servo/servo/blob/518ef39cfd429082dd8dc0d5b13e2db637d08a53/tests/html/webvr/vr-presentation.html#L205

[10:41:35.0000] <KiChjang>
so, whenever a VR device is in or out of present mode

[10:42:27.0000] <smaug>
KiChjang: so is that some very often fired event? I don't thinks so

[10:45:12.0000] <KiChjang>
it depends on how many times you call requestPresent to get your VRDispaly

[10:45:36.0000] <KiChjang>
here's the polyfill of it

[10:45:37.0000] <KiChjang>
https://github.com/servo/servo/blob/518ef39cfd429082dd8dc0d5b13e2db637d08a53/tests/html/webvr/js/third-party/webvr-polyfill.js#L263

[14:28:06.0000] <bterlson>
Where would I find the spec'd semantics for Object.prototype.toString.call(cross-origin window object)?

[14:28:33.0000] <bterlson>
If accessing Symbol.toStringTag cross-origin throws (which I think it should) then this call should fail as well with my naive reading

[14:29:03.0000] <bterlson>
Chrome is giving [object Object] so perhaps there is some spec'd fallback somewhere?

[14:29:07.0000] <bterlson>
Domenic: ^ :)

[14:29:39.0000] <Domenic>
Chrome is probably not super-compliant here. But I know exactly where to look for the spec, one minute

[14:30:10.0000] <Domenic>
bterlson: https://html.spec.whatwg.org/#crossorigingetownpropertyhelper-(-o,-p-)

[14:30:32.0000] <Domenic>
so crossOriginWindow[Symbol.toStringTag] should always give undefined.

[14:31:19.0000] <bterlson>
nice this is exactly what I was looking for

[14:31:28.0000] <bterlson>
therefore Chrome is compliant

[14:31:36.0000] <Domenic>
Oh yay

[14:31:41.0000] <Domenic>
The full spec for Window is at https://html.spec.whatwg.org/#the-windowproxy-exotic-object FYI

[14:32:00.0000] <Domenic>
Although https://github.com/whatwg/html/pull/2400 is in flight I guess

[14:32:11.0000] <bterlson>
although HTML might consider adding an entry for Window to https://tc39.github.io/ecma262/#sec-object.prototype.tostring so as to preserve legacy [object Window] toString for window detection purposes

[14:33:51.0000] <Domenic>
So that'll work same-origin I think

[14:34:08.0000] <Domenic>
CrossOriginGetOwnPropertyHelper only gets invoked for cross-origin windows

[14:44:48.0000] <bterlson>
right, but prior to toStringTag you could still get object Window as the tostring of a cross-origin window

[14:45:00.0000] <bterlson>
(I think)

[14:45:41.0000] <bterlson>
a change to O.p.toString would handle the case when a window object doesn't have a toStringTag (or returns undefined because its cross origin)

[14:45:47.0000] <bterlson>
Domenic: ^

[14:46:14.0000] <Domenic>
I think prior to toStringTag it probably wasn't specified very well

[14:46:32.0000] <Domenic>
If we wanted to make [object Window] work cross-origin we'd ideally just give its toStringTag a value?

[14:46:41.0000] <Domenic>
I assume since it's already configurable that isn't some kind of bad information leak

[15:13:11.0000] <bterlson>
Domenic: you can't access the property cross-origin

[15:13:22.0000] <bterlson>
or else you'd have to ensure it's not a getter or proxy with a trap that is going to execute code

[15:13:53.0000] <Domenic>
I mean we can make crossOriginWindow[Symbol.toStringTag] return whatever we want

[15:13:57.0000] <Domenic>
Right now we make it return undefined

[15:13:59.0000] <bterlson>
ohhh

[15:14:05.0000] <bterlson>
sure right

[15:14:26.0000] <bterlson>
if you have a place for that it'd work too

[15:14:52.0000] <bterlson>
I bring this up because F12 uses O.p.toString for detecting window objects

[15:14:57.0000] <bterlson>
maybe it exists in real code too

[15:42:48.0000] <Domenic>
bterlson: do you know what different browsers do for O.p.toString on cross-origin windows? If there's disagreement then we should maybe change the spec

[15:44:53.0000] <bterlson>
Domenic: I only know Chrome (returns undefined) and Edge (throws permission denied)

[15:45:17.0000] <bterlson>
Edge is just wrong per your previous linkage, but neither preserves legacy behavior

[15:45:32.0000] <Domenic>
I just don't know if "legacy behavior" is the right term here

[15:45:38.0000] <Domenic>
Cross-origin windows have always been wonky

[15:45:48.0000] <Domenic>
So I'm not sure such code ever worked

[15:51:03.0000] <bterlson>
Domenic: me either ;) FF returns undefined per spec as well, can't check safari of course

[15:51:25.0000] <Domenic>
Yeah spec sounds pretty good to me then :)


2017-03-03
[01:46:37.0000] <zcorpan>
should we add dropzone to Obsolete?

[01:48:03.0000] <Ms2ger>
Sure

[02:02:21.0000] <MikeSmith>
yeah

[02:24:32.0000] <annevk>
JakeA: is there a service worker F2F agenda? Could you put https://github.com/whatwg/fetch/issues/492 on it

[02:24:44.0000] <annevk>
JakeA: I won't be there, but it seems good to have it discussed

[03:00:51.0000] <JakeA>
annevk: agreed! Want to look at fetch cancellation too

[04:43:58.0000] <gsnedders>
where is it spec'd that web fonts block the load event?

[04:51:33.0000] <gsnedders>
or is that not true any more?

[04:55:22.0000] <gsnedders>
it seems to be defined through "A resource's critical subresources are those that the resource needs to have available to be correctly processed. Which resources are considered critical or not is defined by the specification that defines the resource's format.

[04:55:41.0000] <gsnedders>
but nobody has ever asked the CSS WG to define what the critical subresources of a stylesheet are

[04:55:44.0000] <gsnedders>
AFAICT

[04:58:56.0000] <annevk>
gsnedders: stylesheet fetching is certainly underdefined

[04:59:24.0000] <annevk>
gsnedders: I also recall a desire to delay load for fonts though

[04:59:29.0000] <gsnedders>
annevk: is there an issue anywhere?

[04:59:42.0000] <annevk>
gsnedders: not sure

[05:00:08.0000] <gsnedders>
W3C HTML seems to say for CSS only @import is a critical subresource

[05:00:22.0000] <gsnedders>
I haven't looked in history to see if that was formally in WHATWG HTML yet

[05:03:04.0000] <gsnedders>
/me waits for git blame

[05:18:29.0000] <gsnedders>
Ah, https://github.com/whatwg/html/commit/89cff9a51f24174c2efca73fa2964e6cd258c541 is the change

[05:18:33.0000] <gsnedders>
based on https://www.w3.org/Bugs/Public/show_bug.cgi?id=17011

[05:24:28.0000] <gsnedders>
which was reassigned to CSS in 2012 by hixie for the sake of defining what its crtiical subresources are

[07:02:28.0000] <zcorpan>
MikeSmith: https://travis-ci.org/whatwg/html/builds/207366283

[08:12:10.0000] <smaug>
foolip: want to start warn about sync XHR too? (I was just reading about >>>)

[08:26:56.0000] <tobie>
annevk: FYI: you might find some discrepancies in pr-preview between the HTML diff and the GH diff.

[08:27:24.0000] <tobie>
annevk: I've identified what the issue is (the GH API is doing something weird)

[08:27:29.0000] <annevk>
tobie: yeah, I think I do every now and then

[08:27:46.0000] <annevk>
tobie: didn't really get to the bottom of it yet, but also haven't used it much thus far

[08:27:54.0000] <tobie>
annevk: their support is amazing though

[08:27:55.0000] <annevk>
tobie: appreciate the heads up

[08:28:10.0000] <tobie>
annevk: and I now know how to work around it

[08:28:28.0000] <tobie>
annevk: tracking it here: https://github.com/tobie/pr-preview/issues/3

[08:28:47.0000] <tobie>
annevk: a fix shouldn't be too difficult

[08:29:09.0000] <tobie>
annevk: but it won't be earlier than next week at best

[11:35:29.0000] <noah_>
hi.. i have a question about this test https://github.com/w3c/web-platform-tests/blame/e32ff14a75f30de31fb1f7ab4e7bd064dfdbfa8a/url/urltestdata.json#L4543 - i think the domain is invalid according to idna2008, so i would expect host parsing to return failure https://url.spec.whatwg.org/#host-parsing

[11:37:47.0000] <annevk>
noah_: does UTS 46 reject it?

[11:40:02.0000] <noah__>
annevk: yes, at least https://pypi.python.org/pypi/idna does

[11:40:58.0000] <noah__>
on the other hand, maybe the whatwg spec should fall back on idna2003 if idna2008 fails, i think that might be what browsers do

[11:41:10.0000] <annevk>
noah__: hmm, file an issue against URL? I can look next week

[11:43:46.0000] <noah__>
ok

[12:50:47.0000] <smaug>
/me wonders https://html.spec.whatwg.org/multipage/browsers.html#is-a-registrable-domain-suffix-of-or-is-equal-to

[12:51:06.0000] <smaug>
why the word registrable there

[13:19:48.0000] <domfarolino>
In infra (https://infra.spec.whatwg.org/#collect-a-sequence-of-code-points), assume given input string "abc", position pointing to beginning of input, and condition "!= a" what should the algo return? "bc" or ""?

[13:20:35.0000] <domfarolino>
I assumed it should return "bc", but it seems since first iteration fails the while condition's second part (after then `and`), it will return ""

[13:39:50.0000] <domfarolino>
actually I think im wrong, it should return "" since we're not collecting ALL codepoints from input that meet a certain condition, just the ones starting at `position` in `input`

[13:51:44.0000] <Domenic>
domfarolino: definitely ""

[13:51:54.0000] <Domenic>
the loop breaks once the condition is met

[13:52:07.0000] <Domenic>
It might be good to add an example

[13:59:00.0000] <Domenic>
terinjokes: robertkowalski: ping on https://github.com/whatwg/console/pulls :)

[13:59:16.0000] <terinjokes>
Domenic: i've been getting the emails

[13:59:22.0000] <terinjokes>
i'm just busy this month

[13:59:32.0000] <Domenic>
terinjokes: ah ok, no problem

[13:59:37.0000] <domfarolino>
Domenic: Thanks! yeah I wasn't sure if it was looking for contiguous codepoints that meet a condition or all..makes sense

[14:00:49.0000] <domfarolino>
Domenic: I had a question the other day about HTML spec and Anne told me you'd be the best person to wait for to ask...it revolves around this algorithm here https://html.spec.whatwg.org/multipage/webappapis.html#uninstantiated-inclusive-descendant-module-scripts

[14:01:49.0000] <domfarolino>
Is the second condition in step 4 > substep 2 a bit redundant? We should not have to check existence in stack right?

[14:02:33.0000] <Domenic>
domfarolino: hmm why not? Remember module graphs can contain cycles

[14:04:43.0000] <domfarolino>
I could be looking at it wrong, but on a graph with cycles I feel that omitting existence checks in `stack` will only change the order of the modules in the returned set, as once they are added to the ID array (marked visited), they will not be re-added once we get to them  further down the stack

[14:06:38.0000] <domfarolino>
I'm trying to come up with an example where omitting existence checks in the stack does not yield a proper DFS

[14:07:07.0000] <Domenic>
It might be true that it only changes the order, although I imagine it will do redundant work regardless?

[14:07:24.0000] <Domenic>
Another issue is that while right now the order doesn't matter there have been some contemplated spec changes where it might

[14:10:56.0000] <domfarolino>
it may do redundant work regardless Im not sure. that makes sense, yeah if order could matter better keep it

[14:11:48.0000] <domfarolino>
I guess I was looking at it from a perf perspective too, in that existence in a stack may not be ideal to perform a ton, though thats probably irrelevant to focus on in the spec.

[14:12:42.0000] <Domenic>
Yeah, most likely implementations would be keeping this data in some side structure as they build the original graph

[14:14:27.0000] <domfarolino>
cool thanks for the info

[15:22:27.0000] <tobie>
jyasskin: looking at the permission spec. Trying to clean-up the integration of the permission spec in the sensor work, as pretty much everything changed under me.

[15:22:54.0000] <tobie>
jyasskin: it would be great to see examples of how this can be integrated in specs

[15:23:59.0000] <tobie>
jyasskin: For example, in the generic sensor spec, I want to check for the permission to use a given sensor.

[15:24:22.0000] <jyasskin>
tobie: Yes. I'm in a C++ meeting this week and on vacation the next, but I can help with that the next.

[15:24:22.0000] <tobie>
jyasskin: what language should I use to do that?

[15:24:46.0000] <tobie>
enjoy the C++ meeting and the vacation. :)

[15:25:04.0000] <jyasskin>
tobie: There's a term, I think "permission state", to get the current permission state.

[15:25:39.0000] <tobie>
jyasskin: right, but it's unclear who calls the boolean permission request algorithm

[15:25:46.0000] <tobie>
or who passes it what arguments

[15:26:25.0000] <tobie>
my case is a bit complicated, because I have all the logic in one spec

[15:26:47.0000] <tobie>
and then other specs just basically specify a permission descriptor

[15:27:22.0000] <tobie>
now it seems I have to move part of this logic in the registry

[15:28:31.0000] <tobie>
but then I somehow need to split it up between multiple PermissionDescriptors

[15:28:51.0000] <tobie>
Happy to look when you're back.

[15:37:51.0000] <jyasskin>
tobie: Only permissions.request() can call the boolean permission request algorithm.

[15:38:17.0000] <jyasskin>
tobie: for another spec to request a permission, you use https://w3c.github.io/permissions/#requesting-more-permission

[15:38:55.0000] <jyasskin>
We can try to fix things once I'm back.

[15:38:58.0000] <tobie>
oh, nice. there they are.

[15:42:12.0000] <tobie>
jyasskin: so I guess I can just make my revocation algorithm for ambient light sensor in the registry call my revocation algorithm specified in the generic sensor spec, passing sensor type as an argument

[15:42:35.0000] <tobie>
jyasskin: think I have all I need, now.

[15:42:38.0000] <tobie>
Thanks

[15:42:41.0000] <jyasskin>
Sounds reasonable.

[15:43:01.0000] <tobie>
well, it's a lot of indirection


2017-03-04
[16:51:59.0000] <foolip>
smaug____: synx XHR actually already has a deprecation message, but not with a date or anything to suggest when/if it'll be removed

[16:52:15.0000] <smaug____>
oh, great

[16:52:30.0000] <smaug____>
foolip: Mutation Events too ?

[16:53:17.0000] <foolip>
which I consider a bug. if it seemed plausible that it'd get the job done, I'd support giving it 1 year until removal, but I think the usage there is much too spread out in different kinds of libraries and other hard-to-update places

[16:53:55.0000] <foolip>
smaug____: I haven't personally looked very closely at the prospects for Mutation Events, but someone (tm) really should come up with a plan for that :)

[16:54:23.0000] <foolip>
but not me, not today, it's Saturday morning and Tokyo requires my attention :)

[16:54:27.0000] <smaug____>
I don't think we can get rid of horrible APIs in the platform if browsers don't warn about their usage

[16:54:52.0000] <smaug____>
it is Saturday indeed

[16:56:21.0000] <foolip>
smaug____: smaug____ in https://github.com/whatwg/xhr/issues/20 I said a lot of what I think about deprecations to drive removals

[16:57:26.0000] <foolip>
short story is I'm skeptical that it's enough, there are other ways to drive down the usage that are more active, but we haven't actually tried the 1-year thing, so it's possible it's not as hopeless as I think

[17:02:16.0000] <smaug____>
hmm, what has happened to mutation events usage. Gecko telemetry says it is very low

[17:04:34.0000] <smaug____>
sync XHR is down too

[17:05:52.0000] <smaug____>
https://www.chromestatus.com/metrics/feature/timeline/popularity/465 is quite promising, I'd say

[17:06:46.0000] <Domenic>
One has to wonder if that's just the internet getting bigger :P

[17:07:22.0000] <Domenic>
but yeah, foolip and I often debate this, I like pretending it will linearly extrapolate to zero, whereas he's more realistic and thinks it's likely leveling off

[17:08:33.0000] <foolip>
good point, a constant number of affected users would still look like a 1/x graph or similar

[17:09:40.0000] <smaug____>
big sites like Google was using sync XHR and then at some point dropped it, I think around the time certain browsers started to warn about its use

[13:39:26.0000] <tobie>
annevk: fixed the html diffs issue in pr-preview. LMK if you spot anything weird.


2017-03-05
[20:18:05.0000] <MikeSmith>
does Subresource Integrity define a protocol?

[20:19:16.0000] <MikeSmith>
or else whatever it does define, what specific technical term would be approprite to describe it?

[20:19:44.0000] <MikeSmith>
the abstract just says, “This specification defines a mechanism”

[20:19:54.0000] <MikeSmith>
mechanism

[20:20:39.0000] <MikeSmith>
in contrast the CSP spec says, “This document defines a policy language”

[22:06:17.0000] <annevk>
MikeSmith: feature 😛

[02:33:57.0000] <MikeSmith>
annevk: Yeah I am beginning to realize it's futile to try to classify specs into discrete types

[03:57:55.0000] <annevk>
MikeSmith: we don't really have sufficient understanding of what we're doing for that

[14:40:37.0000] <MikeSmith>
annevk: yeah it was not my idea to try to classify them to begin with. I was asked to look into creating some guidance for testing based on spec types.

[14:42:59.0000] <MikeSmith>
Anyway after talking with foolip I think it still makes some sense to trying to give testing guidance based on spec features but instead based on identifiable things like, Does the spec define interfaces (using WebIDL)? Does the spec define new HTTP headers or new HTTP header values? Does the spec define new elements, attributes, or attribute values?

[14:43:04.0000] <MikeSmith>
etc


2017-03-06
[23:14:59.0000] <annevk>
MikeSmith: yeah, topics make sense

[23:42:52.0000] <yoav>
zcorpan: thoughts on https://github.com/whatwg/fetch/pull/437 ?

[23:45:08.0000] <zcorpan>
yoav: I'm OK with separating video and audio. But I would be interested in when/where they diverge in the network stack in implementations later

[23:57:18.0000] <yoav>
zcorpan: currently they're the same resource type internally in Chrome

[23:57:49.0000] <yoav>
but I guess that may change in the future, and not sure that's true for all browsers

[01:34:55.0000] <MikeSmith>
the HTML used to day the `defer` must not be specified for `script` elements that don’t also have a `src` attribute

[01:35:01.0000] <MikeSmith>
I guess we changed that?

[01:35:48.0000] <annevk>
MikeSmith: not intentionally, I think

[01:38:37.0000] <MikeSmith>
oh OK

[01:38:43.0000] <MikeSmith>
will ping Domenic about it then

[02:12:40.0000] <zcorpan>
MikeSmith: seems like a regression introduced by <script type=module>

[02:12:49.0000] <MikeSmith>
yeah

[02:12:54.0000] <MikeSmith>
will raise a PR for it

[02:13:15.0000] <MikeSmith>
https://github.com/whatwg/html/commit/cd1a9fb1e83f7d0bc30be8b34ecdaf444a0b19a4#diff-36cd38f49b9afa08222c0dc9ebfe35ebL59339

[02:14:34.0000] <MikeSmith>
caught by having just happened to look back at an old Stackoverflow question http://stackoverflow.com/questions/38291503/code-defer-not-w3-valid/42622772#42622772

[02:19:01.0000] <MikeSmith>
in other news also just noticed this new (CSS) question: https://stackoverflow.com/questions/42622197/were-there-any-technical-limitations-within-css-that-led-to-the-decision-of-usin

[02:19:21.0000] <MikeSmith>
“Were there any technical limitations within CSS that led to the decision of using `--` for vars?”

[02:47:00.0000] <annevk>
Hmm, did Bikeshed regress again?

[02:47:08.0000] <annevk>
Builds are failing again

[02:47:56.0000] <annevk>
Hmm indeed

[02:47:57.0000] <annevk>
FATAL ERROR: 'Default Biblio Status' must be either 'current' or 'snapshot'. Got 'current'

[02:48:02.0000] <annevk>
after updating Bikeshed locally

[02:48:11.0000] <annevk>
fuck

[02:48:14.0000] <annevk>
(sorry)

[02:50:18.0000] <annevk>
/me files https://github.com/tabatkins/bikeshed/issues/941

[02:50:50.0000] <annevk>
It's really rather scary how unstable Bikeshed is

[02:51:12.0000] <annevk>
And I doubt anyone verifies the actual output much other than folks that occasionally read the standard

[02:51:25.0000] <annevk>
Still not entirely sure it's a win over Anolis

[03:01:20.0000] <csarven>
The ordering of the elements in table is not so fun here: https://www.w3.org/TR/html/tabular-data.html#the-table-element and https://www.w3.org/TR/html5/tabular-data.html#the-table-element .. in particular to tfoot appearing before tbody. https://www.w3.org/TR/html401/struct/tables.html#h-11.2.3 required tfoot before tbody

[03:02:33.0000] <annevk>
I'm not sure what is not fun

[03:02:42.0000] <csarven>
https://www.w3.org/wiki/HTML/W3C-WHATWG-Differences doesn't mention the differences.

[03:02:48.0000] <annevk>
OR what you're trying to say, rather

[03:03:32.0000] <annevk>
csarven: https://html-differences.whatwg.org/#content-model lists it

[03:03:43.0000] <csarven>
Perhaps I'm misinterpreting TR/html/ but it seems to be that tfoot can't come before tbody?

[03:04:13.0000] <annevk>
csarven: doesn't it say that it can?

[03:08:31.0000] <csarven>
https://www.w3.org/TR/html/tabular-data.html ?  It doesn't seem like it. Again, perhaps I'm overlooking a wording here.

[03:08:47.0000] <csarven>
re: https://html-differences.whatwg.org/#content-model hints at the possibility "The table element now allows the tfoot element to be the last child."

[03:09:52.0000] <csarven>
I just wanted a clarification. I'm okay to only use it after tbody but earlier publications used tfoot before tbody and was wondering whether that's still "okay" as far as HTML5 is concerned.

[03:16:28.0000] <annevk>
Hmm I guess you're right

[03:16:37.0000] <annevk>
I don't really know anything about fork HTML though

[03:16:57.0000] <annevk>
Well, I know some things, such as that it contains bugs and that it's rather poorly maintained

[04:01:20.0000] <yoav>
annevk: If I read https://github.com/whatwg/fetch/issues/355 correctly, it is still possible to handle opaque responses as a stream. Is that correct?

[04:03:33.0000] <annevk>
yoav: a non-exposed stream, yes

[04:11:02.0000] <yoav>
annevk: ok, cool

[05:00:14.0000] <annevk>
hendry: re Twitter it's a little unclear to me what you're trying to do

[05:00:29.0000] <annevk>
hendry: do you want to display PDF inside an <iframe> or some such?

[05:01:27.0000] <annevk>
hendry: if you want to display the PDF using standards you'd need https://github.com/mozilla/pdf.js

[06:16:25.0000] <zcorpan>
yoav: the commit message still talks about `Accept`...?

[06:17:27.0000] <yoav>
I can remove that part

[07:49:46.0000] <Domenic>
Yeah Bikeshed woes are not great

[07:50:08.0000] <Domenic>
The fact that the build is red half the time according to https://github.com/tabatkins/bikeshed/commits/master does not inspire confidence that the changes are tested locally before pushing

[07:50:35.0000] <Domenic>
and commits that fix something but don't add a new test to prevent regressions are scary

[07:51:02.0000] <Domenic>
but i guess if the tests mostly don't pass them it's harder to add new tests

[07:51:04.0000] <TabAtkins>
Yeah, sorry about this. It was a big refactoring job that I assumed didn't need extra testing. 😑

[07:51:33.0000] <TabAtkins>
Tests almost always go red for trivial rebasing reasons

[07:51:44.0000] <Domenic>
doesn't mean they shouldn't be fixed before pushing

[07:52:57.0000] <TabAtkins>
Yeah, you're right. When people were usually pulling Bikeshed manually or was okay to let Travis catch failures, but I need to be more disciplined about catching them before I push, not 30 minutes later.

[08:02:54.0000] <TabAtkins>
But also: seriously wtf is this damn error about.

[08:03:35.0000] <TabAtkins>
I switched biblio/ref status from being a plain string to being an enum, and it's claiming one of the enum values isn't in the enum. :(

[08:20:07.0000] <Domenic>
my guess was that in the 'x' is not an 'x', one of the 'x's is an enum and the other is a string

[08:26:39.0000] <TabAtkins>
No, that's fine. Finally tracked it down, pushing now.

[08:28:29.0000] <TabAtkins>
I'd tested `"foo" in enum` and `foo["enum"]`, and foolishly assumed that `foo(enum)`, which *appeared* be the identical to using square braces except it allowed enum instances, would do the same.

[08:28:54.0000] <TabAtkins>
(Sorry, enum["foo"] and enum("foo").)

[08:29:41.0000] <TabAtkins>
The calling syntax instead does a *by value* search, and the enum are auto-numbered by default, so their value was an int, not a string. :(

[08:30:05.0000] <TabAtkins>
This enum class is supposedly matching the enum PEP, but jeezus it's kinda shitty for what feels like standard-ass usage.

[08:42:30.0000] <Domenic>
Great :). Hope the fix commit includes a test to prevent future regressions!

[08:42:59.0000] <TabAtkins>
Will in a sec, was pushing the fix first after testing it locally. ^_^

[09:02:10.0000] <annevk>
hurray

[11:12:02.0000] <MikeSmith>
csarven: https://github.com/whatwg/html/commit/94d55af9cda601ce675d15f6a0e52c9bb9c6afa9

[11:13:01.0000] <MikeSmith>
csarven: from https://github.com/whatwg/html/issues/352

[11:13:43.0000] <MikeSmith>
> In HTML4, `tfoot` had to appear before `tbody`, but HTML5 allowed either before or after. Placing it before causes problems for keyboard focus order and order of accessibility objects, so this changes the content model to no longer allow `tfoot` before `tbody`.

[12:12:16.0000] <csarven>
MikeSmith Thanks for that!

[12:13:30.0000] <csarven>
My intuition as to why tfoot was suggested to go before tbody was also so that legend-like info can be read/interpreted before looking at the tbody.

[12:13:44.0000] <csarven>
But if that was really the case, I would expect tfoot come even before thead

[12:14:06.0000] <csarven>
Any way.. good to have context for the current state of the spec

[12:14:59.0000] <csarven>
I use tfoot all the time. And before tbody. Doing that out of old habit re HTML 4.01.

[12:15:08.0000] <csarven>
Will update.

[12:28:01.0000] <KiChjang>
is "refactoring the web" pretty much well-nigh impossible without causing a lot of breakage, angry protests and churn?

[12:32:44.0000] <Domenic>
Well, by at least some definitions, refactoring literally means no changes to observable behavior, so it should be fine

[15:58:05.0000] <jsbell>
Domenic: dom.spec.whatwg.org hasn't picked up the latest commit; something broken or need poking, or am I missing something (as usual...) ?


2017-03-07
[16:08:41.0000] <TabAtkins>
jsbell: Travis was failing earlier due to a Bikeshed bug, so it just needs a poke (or another commit).

[16:09:45.0000] <jsbell>
Thx. If a WHATWG-empowered person could poke it I'd appreciate it; I want to link to a new dfn in the commit.

[18:53:40.0000] <Domenic>
botie: tell jsbell I poked it https://travis-ci.org/whatwg/dom/builds/208150332

[18:53:40.0000] <botie>
will do

[00:58:38.0000] <nox>
annevk: https://github.com/w3c/web-platform-tests/issues/2499#issuecomment-284365616 Months later I'm afraid I don't remember. :P

[04:24:19.0000] <smaug>
foolip: https://www.chromestatus.com/metrics/feature/timeline/popularity/865 gives me AddEventListenerFourArguments

[04:25:13.0000] <smaug>
oh, it is just slow to update

[04:45:47.0000] <foolip>
smaug: sounds like https://github.com/GoogleChrome/chromium-dashboard/issues/220

[04:46:28.0000] <smaug>
ah, yes

[06:02:37.0000] <annevk>
jgraham: here's a case where it's been hard to find a reviewer: https://github.com/w3c/web-platform-tests/pull/4811

[06:04:00.0000] <annevk>
jgraham: I actually do find myself sometimes landing certain changes to XMLHttpRequest without review, just because the level of interest is really low

[06:13:58.0000] <jgraham>
annevk: I'm totally happy with the level of review than Domenic gave in that case

[06:15:08.0000] <Domenic>
"Please refer to the URL Continually Updated Specification" lol (from https://www.w3.org/TR/url-1/ )

[06:15:41.0000] <jgraham>
annevk: I mean, I am sympathetic to your concern :/

[09:10:19.0000] <botie>
jsbell, at 2017-03-07 02:53 UTC, Domenic said: I poked it https://travis-ci.org/whatwg/dom/builds/208150332

[09:19:50.0000] <alextes>
aaaah this is where you guys hide

[09:19:56.0000] <alextes>
I'm looking for stevenvachon

[09:20:08.0000] <alextes>
but maybe someone else can answer this question for me too

[09:24:33.0000] <alextes>
Steven suggested we add whatwg-url support to a tiny request lib I like to help maintain. Node only. It supports Node v4+ (maybe in a month v6+), that begs the question how to support whatwg-url in earlier node versions. However, after contemplating this a bit I realised it's likely Steven just meant to suggest for the lib to seamlessly support whatwg-url on Node v8+. Currently it does something before passing to Node's http module which breaks this. I'm

[09:24:33.0000] <alextes>
 hoping there are folks from the workgroup here that know about an effort to get libs everywhere to seamlessly start supporting whatwg-url when Node does.

[09:25:05.0000] <alextes>
Giving stevenvachon a mention would also be hugely appreciated, can't track down his handle :[

[09:37:22.0000] <annevk>
alextes: I think steven is sometimes here under that handle, some folks here help maintain whatwg-url and then separately Node.js added a native URL library recently that conforms to the same standard

[09:40:45.0000] <Domenic>
alextes: I maintain the jsdom/whatwg-url npm package, but I can't quite understand your problem.

[09:44:51.0000] <Sebmaster>
alextes: Node has an implementation of the URL standard natively nowadays. The whatwg-url package independently implements the whole spec and could be used to shim that capability for older versions which do not support it.

[12:11:24.0000] <JoWie>
instances of HTMLObjectElement are typeof "function" in firefox and chrome. where can i find this in the html spec? or has this never been specced?

[12:47:53.0000] <jsbell>
JoWie: That'd be in https://heycam.github.io/webidl/#es-interfaces

[12:50:41.0000] <smaug>
how do people review spec changes when specs tend to use so overlong lines

[12:50:58.0000] <smaug>
and github has the worst tooling for reviewing

[12:51:02.0000] <jsbell>
Oh, instances, hrm...

[12:52:30.0000] <TabAtkins>
smaug: Yell at those specs for using shitty line-breaking, and recommend they use semantic linefeeds http://rhodesmill.org/brandon/2012/one-sentence-per-line/ like a civilized person.

[12:52:40.0000] <jsbell>
JoWie: sorry, ignore my previous comment. Looking...

[12:53:23.0000] <smaug>
JoWie: FWIW, I get "object" in FF

[12:53:30.0000] <smaug>
Chrome for some reason gives function

[13:16:12.0000] <jsbell>
joWie: HTMLObjectElement and HTMLEmbedElement used to have legacycaller applied. Defined https://heycam.github.io/webidl/#idl-legacy-callers and removed https://github.com/whatwg/html/pull/1979/files  - Gecko (FF) removed recently https://bugzilla.mozilla.org/show_bug.cgi?id=909656 but Blink (Chrome) has not yet https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/MuxvaXiyBxU/GRICeJm0hHkJ

[13:18:13.0000] <jsbell>
Oh, blink removed too, just hasn't hit stable yet (landed Feb 13)

[13:18:23.0000] <jsbell>
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/AiDZ7ru9mGg/_D_9Fcc2AwAJ

[13:18:26.0000] <jsbell>
So that should go away soon

[13:20:08.0000] <JoWie>
jsbell: ah thanks

[13:53:50.0000] <alextes>
thank you for the replies annevk Domenic Sebmaster

[13:54:28.0000] <alextes>
So to Domenic and Sebmaster a shim for older versions is nice, but what I'm unclear on is how you would then expect people to use the node modules that expect their own 'options' object for older versions.

[13:54:43.0000] <Domenic>
alextes: what options object are you talking about?

[13:54:59.0000] <alextes>
https://nodejs.org/api/http.html#http_http_request_options_callback

[13:55:36.0000] <Domenic>
alextes: oh, I don't know, whatwg-url wasn't meant to be used with that

[13:55:54.0000] <alextes>
Alright.

[13:57:58.0000] <alextes>
I guess I should ask node folks how they feel about throwing a whatwg-url href into the node url parser.

[14:00:17.0000] <Sebmaster>
alextes: Why not just serialize out the fully resolved url to a string?

[14:00:33.0000] <Sebmaster>
Before you provide it to the options object

[14:00:52.0000] <alextes>
I thought this is what href was from looking at: https://nodejs.org/api/url.html#url_url_href

[14:01:53.0000] <alextes>
I guess 'toString' is more appropriate :]

[14:01:58.0000] <alextes>
is that what you meant?

[14:04:20.0000] <alextes>
Sebmaster ^

[14:04:57.0000] <Sebmaster>
No I mean why are you not calling this yourself before sticking it into the request object?

[14:18:59.0000] <alextes>
Sebmaster because node v4 doesn't have it.

[14:19:18.0000] <alextes>
If I use the shim I still don't have something I can pass to node's http modules.

[14:20:02.0000] <alextes>
But I'd say perhaps serialising at that point is acceptable. I don't know in which scenarios whatwg-url might serialise to something node v4 does not support.

[14:22:04.0000] <Sebmaster>
alextes: if you use the shim, you can just serialize with .href and can pass it in

[14:22:18.0000] <alextes>
Alright, good to know, thanks!


2017-03-08
[19:05:08.0000] <noah>
this step of the ipv6 serializer is nutso "If compress pointer points to piece, append "::" to output if piece is address’s first piece and append ":" otherwise, and then run these substeps again with all subsequent pieces in address’s pieces that are 0 skipped or go the next step in the overall set of steps if that leaves no pieces."

[19:05:50.0000] <terinjokes>
ugh, I just stumbled into IDN

[20:12:21.0000] <terinjokes>
i have a headache now, sorry URL project for my ramblings ;)

[21:52:56.0000] <annevk>
terinjokes: IDNA is the good stuff

[21:54:40.0000] <annevk>
botie: tell smaug that WHATWG pull requests should have a link to a readable diff these days

[21:54:41.0000] <botie>
will do

[21:55:19.0000] <annevk>
botie: tell noah we can reword the IPv6 serializer to make it clearer

[21:55:19.0000] <botie>
will do

[22:54:28.0000] <terinjokes>
annevk: asking with my work hat one: is it recommended at this point that we start moving systems to IDA2008+non-transitional?

[22:56:32.0000] <terinjokes>
i discovered today that in different parts of the stack we're handling IDNs a couple of different ways

[23:03:50.0000] <terinjokes>
(i guess having one recommendation, even if that's IDA2003, is better than the random mix we seem to be doing right now)

[23:52:07.0000] <annevk>
terinjokes: my recommendation is UTS46 non-transitional

[23:52:29.0000] <annevk>
terinjokes: even UTS46 transitional uses a dataset that is modified-IDNA2008

[23:53:07.0000] <annevk>
terinjokes: I'm hoping that Chrome and Edge will come around now Firefox and Safari have proven the way

[23:53:36.0000] <annevk>
terinjokes: there's definitely still pitfalls even if they all agree, but that's mostly to do with UTS46

[00:14:31.0000] <annevk>
JakeA: mnot just found out that CORS cache issue Chrome has: https://github.com/whatwg/fetch/issues/307

[00:14:40.0000] <annevk>
JakeA: seems surprising that it's still not fixed

[00:15:14.0000] <annevk>
JakeA: for all the security issues Googlers tweet about I sure find Chrome is rather lacking when it comes to its own same-origin policy breakage

[01:14:38.0000] <JakeA>
annevk: on holiday right now, but will chase this

[01:14:58.0000] <annevk>
JakeA: oh right, when are you back?

[01:15:44.0000] <annevk>
JakeA: anyway enjoy and please try to forget I pinged you about this

[01:30:45.0000] <annevk>
https://github.com/whatwg/html/pull/2421 is very exciting

[01:59:14.0000] <zcorpan>
hmm. the lint check for may in example doesn't work unless the class="example" and the may are on the same line.

[02:09:20.0000] <annevk>
/me unsubscribes from www-dom

[02:13:11.0000] <annevk>
www-dom used to be a great list for technical discussions about the DOM and then somehow it got turned into a process mess and now GitHub digests?!

[02:34:14.0000] <Ms2ger>
/me unsubscribes too

[02:44:18.0000] <annevk>
How long have default arguments worked in JavaScript function declarations?

[02:44:28.0000] <annevk>
Default argument values

[02:49:29.0000] <ondras>
http://kangax.github.io/compat-table/es6/#test-default_function_parameters ?

[02:50:46.0000] <annevk>
Thanks

[02:50:56.0000] <annevk>
It seems this very old looking XHR test was recently modified

[02:51:16.0000] <annevk>
I was thinking we had this feature for ages and I didn't know about it

[02:57:20.0000] <ondras>
:)

[02:57:23.0000] <ondras>
it is rather new, yes

[03:18:31.0000] <botie>
smaug, at 2017-03-08 05:54 UTC, annevk said: WHATWG pull requests should have a link to a readable diff these days

[03:21:02.0000] <smaug>
ah. This was pointerevers

[03:21:04.0000] <smaug>
events

[05:27:32.0000] <jgraham>
annevk: yt?

[05:27:38.0000] <annevk>
jgraham: yeah

[05:27:39.0000] <jgraham>
<<<<<<< cee5ae75919c5f22318f2e02d9b8a1dfd9fb66c5

[05:27:39.0000] <jgraham>
var referrerOrigin = (new URL("/", location.href)).href;

[05:27:39.0000] <jgraham>
=======

[05:27:39.0000] <jgraham>
var referrerOrigin = self.location.origin + '/';

[05:27:40.0000] <jgraham>
>>>>>>> P3 Test referrer-policy in service workers.

[05:27:47.0000] <jgraham>
Which one is better?

[05:27:57.0000] <jgraham>
in fetch/api/policies/referrer-origin.js

[05:29:20.0000] <annevk>
jgraham: the second can emit non-ASCII in theory

[05:29:23.0000] <annevk>
jgraham: otherwise equivalent

[05:29:51.0000] <annevk>
jgraham: but I'd prefer no change I think since this is probably something where it was already fixed on WPT and Gecko also tried to fix it locally?

[05:32:33.0000] <annevk>
jgraham: if you're merging, any chance you can tell me about all fetch/xhr/cors/url/encoding/dom changes?

[05:32:46.0000] <annevk>
maybe not dom/ I haven't really investigated that much yet

[05:44:22.0000] <jgraham>
annevk: So the top one?

[05:44:37.0000] <jgraham>
Not sure what you want me to tell you?

[05:45:20.0000] <annevk>
jgraham: yeah don't change it (I hadn't actually looked at the resource to see what it was last changed to)

[05:51:04.0000] <jgraham>
annevk: I think the only changes are in fetch/

[05:51:06.0000] <jgraham>
https://pastebin.mozilla.org/8981400

[05:52:23.0000] <annevk>
ta

[08:22:45.0000] <terinjokes>
annevk: it looks like transitional UTF46 still converts ß to ss, which is how i fell down this rabbit hole

[08:23:08.0000] <terinjokes>
i agree though, it what i'll recommend internally

[08:57:43.0000] <annevk>
terinjokes: yeah, it ain't pretty

[09:21:31.0000] <Domenic>
annevk: terinjokes: I'm still wondering if we should spec the rule that implementations seem to have where short origins don't do validation or something...

[09:22:30.0000] <Domenic>
I can't find a tracking issue for that actually hmm

[09:23:31.0000] <annevk>
Domenic: short origin?

[09:23:38.0000] <Domenic>
Trying to find it...

[09:23:43.0000] <Domenic>
Like under 63 characters or something??

[09:23:54.0000] <annevk>
Domenic: ASCII origins?

[09:23:59.0000] <Domenic>
Oh, that was it

[09:24:27.0000] <annevk>
Domenic: I am not having luck in talking to implementers and the UTS46 folks

[09:24:56.0000] <annevk>
Domenic: it's logged as an issue with them, still waiting for replies

[09:25:18.0000] <Domenic>
It'd be good to have a URL tracking issue

[09:25:23.0000] <Domenic>
Since one fix is on the URL side

[09:25:23.0000] <annevk>
Domenic: IDNA and file parsing are the main outstanding URL issues

[09:25:37.0000] <Domenic>
Just don't run ToASCII if it's already ASCII

[09:26:23.0000] <Domenic>
At this point I am pretty sure the discussion is not in whatwg/url... maybe it was in web-platform-tests

[09:26:35.0000] <annevk>
Domenic: sure, just waiting to hear back

[09:27:10.0000] <annevk>
Domenic: I wrote a post, there's also the Google doc linked from the IDNA issue

[09:28:19.0000] <annevk>
Domenic: anyway, feel free to open a dedicated issue, but without dialogue it's gonna be hard to do something

[09:29:29.0000] <Domenic>
Yeah, I just want something to track the issue, since this comes up in whatwg-url vs. browser conversations. I wrote https://github.com/whatwg/url/issues/267 .

[09:31:01.0000] <annevk>
Ta

[09:31:28.0000] <annevk>
I wish the IDNA folks were not mostly absent

[09:39:40.0000] <smaug>
Am I hallucinating: https://html.spec.whatwg.org/#event-loop-processing-model ends up creating /now/ using top level window.performance.now() and passing that value to also fAF callbacks in nested documents

[09:39:54.0000] <smaug>
the top level performance.now() may have nothing to do with child documents

[09:41:49.0000] <smaug>
zcorpan: you might have something to say about ^

[09:46:51.0000] <terinjokes>
Domenic: is there a problem applying ToASCII on ASCII-only imput?

[09:47:21.0000] <terinjokes>
as someone who's currently doing that across multiple environments, i thought it was mostly safe

[09:47:22.0000] <Domenic>
terinjokes: it does extra validations like a length limit or disallowing leading hyphens. Apparently browsers don't do that unless the input contains unicode.

[09:50:12.0000] <smaug>
https://github.com/whatwg/html/issues/2423

[09:50:15.0000] <annevk>
terinjokes: https://annevankesteren.nl/2017/02/idna-toascii-differences

[09:50:31.0000] <annevk>
Domenic: I'm still interested in filing incumbent settings object bugs

[09:51:27.0000] <annevk>
Domenic: for much the same reasons as you're interested in having that IDNA issue filed

[10:22:37.0000] <Domenic>
annevk: sure, if you want, but I don't know what they would say... "the spec currently says something, but we're not sure about it, so please don't change anything yet until we figure out our story?"

[10:23:23.0000] <annevk>
Domenic: hmm, so bz seems confident

[10:23:41.0000] <annevk>
Domenic: but I guess if you're not done yet, we can wait

[10:23:59.0000] <annevk>
Domenic: but it seems like you've been putting in a lot of effort without much guidance from non-Fx

[10:24:03.0000] <Domenic>
I mean I think we are reasonably confident about the definition of incumbent. Just not its usage sites.

[10:24:32.0000] <Domenic>
And there's also the possibility that if we get the number of usage sites down low enough, having a high-fidelity incumbent doesn't matter much, so we could simplify the definition to what non-FF UAs do.

[10:29:37.0000] <annevk>
Okay, guess I'll try to be more patient

[10:38:58.0000] <annevk>
I mean, I will be more patient and thank you for sorting this out, I'm not jealous

[10:44:59.0000] <Domenic>
:)

[10:55:50.0000] <annevk>
Domenic: transfering a stream or anything that spans multiple tasks is best done by associating a private MessageChannel with the object I think

[10:56:19.0000] <annevk>
Domenic: so you have a ReadableStream on both sides, each with their own MessagePort and MessagePort handling logic

[10:56:39.0000] <annevk>
Domenic: and then you transfer the objects through that MessageChannel

[10:57:19.0000] <annevk>
Domenic: the initial clone would set up the MessagePort logic

[10:57:48.0000] <annevk>
Domenic: I can't really think of another primitive that would make something like that work

[10:58:57.0000] <annevk>
Hmm, alshamiri1 is listed as reviewer on all HTML PRs despite not having a GitHub account

[11:03:28.0000] <annevk>
I guess I'll complain to GitHub

[11:07:13.0000] <Domenic>
A private MessageChannel, wow, I never thought of that

[12:40:10.0000] <Domenic>
It's strange but nice that both Gecko and Chrome seem to suddenly be working on making the text selection APIs interoperable

[14:24:32.0000] <wanderview>
argh... why does the service worker spec link to TR for this? https://www.w3.org/TR/page-visibility/#dom-document-visibilitystate

[14:25:08.0000] <wanderview>
I guess there is no draft version?

[14:34:31.0000] <Domenic>
wanderview: there is, https://w3c.github.io/page-visibility/


2017-03-09
[17:21:23.0000] <MikeSmith>
Stackoverflow finally moving away fully from non-TLS https://meta.stackexchange.com/questions/292058/network-wide-https-its-time

[17:33:04.0000] <domfarolino>
about time

[17:49:50.0000] <Domenic>
srsly

[00:24:21.0000] <annevk>
MikeSmith: Bugzilla spam: https://www.w3.org/Bugs/Public/show_bug.cgi?id=30073

[00:24:33.0000] <MikeSmith>
/me looks

[00:35:04.0000] <botie>
noah, at 2017-03-08 05:55 UTC, annevk said: we can reword the IPv6 serializer to make it clearer

[00:36:03.0000] <noah>
annevk: 👍🏻

[00:37:10.0000] <annevk>
noah: if you want, you can even try to do so yourself

[00:37:18.0000] <noah>
wondering why https://github.com/jsdom/whatwg-url uses https://github.com/Sebmaster/tr46.js as opposed to https://github.com/jcranmer/idna-uts46

[00:38:19.0000] <noah>
if i can make sense of it yeah

[00:44:00.0000] <MikeSmith>
Subresource Integrity getting implemented in WebKit https://bugs.webkit.org/show_bug.cgi?id=148363 patch under review

[00:45:30.0000] <noah>
Sebmaster: Domenic: maybe you know the answer?☝🏻

[06:04:01.0000] <wanderview>
Domenic: thanks... so Unloaded is not a thing anymore

[06:11:07.0000] <annevk>
wanderview: would appreciate input on https://github.com/whatwg/fetch/pull/502

[06:15:31.0000] <wanderview>
annevk: I'm sorry, but I don't have an opinion on that... seems fine either way

[06:15:51.0000] <wanderview>
annevk: maybe mcmanus or someone on his team would have an opinion

[06:15:58.0000] <annevk>
wanderview: I mostly want to know whether we can change

[06:16:07.0000] <annevk>
wanderview: I wish it was easier to get input from them

[06:16:25.0000] <annevk>
anyway, thanks

[06:16:29.0000] <wanderview>
annevk: I mean, we can do anything we want... but I doubt we would make a change immediately

[06:16:38.0000] <wanderview>
annevk: sorry, I'm really slammed with this deadline

[06:16:48.0000] <annevk>
wanderview: I found a bug in https://github.com/w3c/web-platform-tests/blob/master/XMLHttpRequest/open-url-redirected-worker-origin.htm and will post a patch to WPT

[06:17:25.0000] <wanderview>
annevk: oh?

[06:17:46.0000] <annevk>
wanderview: I changed a whole lot of XHR infrastructure to be more sensitive to casing

[06:17:58.0000] <annevk>
wanderview: so this test ends up failing because it expects lowercase header names

[06:18:05.0000] <wanderview>
ah, ok

[06:18:32.0000] <wanderview>
sounds good

[06:18:43.0000] <wanderview>
annevk: I was worried the referer behavior was wrong or something

[06:19:12.0000] <wanderview>
annevk: I copied most of that test from another test (like all good tests are created)

[11:31:13.0000] <noah>
annevk: maybe you know? wondering why github.com/jsdom/whatwg-url uses github.com/Sebmaster/tr46.js as opposed to github.com/jcranmer/idna-uts46

[11:33:15.0000] <noah>
i guess idna-uts46 is older... but tr46.js has this worrisome issue https://github.com/Sebmaster/tr46.js/issues/6

[11:34:26.0000] <noah>
is there a decent implementation of uts46 in any language? :-|

[11:36:50.0000] <Sebmaster>
noah: that issue doesn't really count. The unicode tests are... subpar to say the least. A lot of the tests do not apply to uts46

[11:38:38.0000] <noah>
Sebmaster: oh?

[11:39:16.0000] <Sebmaster>
Yeah. It seems there is a single test file for all unicode url standards... which are incompatible with each other sooo

[11:39:20.0000] <Sebmaster>
Doesn't really make sense

[11:39:47.0000] <Sebmaster>
Not quite sure why we didn't use that other lib. Might not have found it in time

[11:40:30.0000] <noah>
you mean IdnaTest.txt i assume, and by "all unicode url standards" do you mean idna2003, idna2008 and uts46?

[11:49:01.0000] <annevk>
noah: I also found IdnaTest.txt problematic: https://lists.w3.org/Archives/Public/www-archive/2017Jan/0011.html

[11:49:27.0000] <annevk>
I haven't really started digging yet because I want to hear from implementers

[11:49:38.0000] <annevk>
And from the UTS46 people

[11:51:37.0000] <noah>
Sebmaster: annevk: well, i took a look at the first test failure "Web Platform Tests Converting <àא> with type B: AssertionError: toASCII should result in an error", and chromium seems to agree with IdnaTest.txt, not with tr46.js

[11:57:30.0000] <noah>
annevk: you ran IdnaTest.txt tests across all browsers and found failures and inconsistencies among browsers. disappointing but good to know, thanks for doing that work

[14:21:02.0000] <zcorpan>
MikeSmith: fyi https://github.com/htacg/tidy-html5/issues/352#issuecomment-285449909

[14:27:13.0000] <MikeSmith>
/me looks

[14:30:04.0000] <MikeSmith>
zcorpan: maybe I should make the checker emit a link to the URL spec in the error messages for URL checks?

[14:30:29.0000] <zcorpan>
MikeSmith: does the checker implement the url spec?

[14:31:52.0000] <MikeSmith>
to the degree that galimatias does

[14:32:02.0000] <MikeSmith>
is it wrong in this case?

[14:32:51.0000] <MikeSmith>
I’m running a fork of galimatias so if it is wrong in any particular case I can just fix it in the fork

[14:33:21.0000] <MikeSmith>
upstream galimatias is no longer being maintained and there are some places where I know it’s not conforming with the current spec

[14:34:23.0000] <MikeSmith>
and I have been having discussions with somebody who may end up providing a new implementation that attempts to fully conform to the current spec and who will maintain it to keep up with any changes to the spec

[14:34:36.0000] <MikeSmith>
but don’t have that in hand yet

[14:34:55.0000] <MikeSmith>
so for now I just have to patch galimatias if any problems are found

[14:35:06.0000] <mounir>
dbaron: any chance I can get your feedback on https://github.com/w3c/csswg-drafts/issues/993 ? :)

[14:35:30.0000] <zcorpan>
i don't know, but was under the impression that galimatias kinda pre-dated whatwg url

[14:36:11.0000] <MikeSmith>
zcorpan: well is there some problem in this particular case? is <a href=":|"> valid?

[14:36:52.0000] <MikeSmith>
is there some online conforming parser I can against?

[14:37:01.0000] <MikeSmith>
I thought annevk maintained one

[14:37:16.0000] <zcorpan>
MikeSmith: https://a/?| is i think?

[14:37:28.0000] <zcorpan>
https://quuz.org/url/liveview.html#https://a/?|

[14:39:12.0000] <zcorpan>
no it's not. https://url.spec.whatwg.org/#url-query-string

[14:39:23.0000] <MikeSmith>
yeah

[14:40:22.0000] <MikeSmith>
so I guess quuz.org/url doesn’t show errors for syntax violations

[14:40:35.0000] <zcorpan>
the code snippet that he posted is an implementation of https://url.spec.whatwg.org/#url-code-points right?

[14:40:45.0000] <MikeSmith>
yup

[14:41:41.0000] <MikeSmith>
though btw what I do in the checker is, it uses http://example.com/foo as the base

[14:42:00.0000] <MikeSmith>
which is arbitrary but it needs a base to parse against

[14:44:38.0000] <MikeSmith>
https://github.com/validator/validator/blob/master/src/nu/validator/datatype/IriRef.java#L129

[14:45:40.0000] <MikeSmith>
anyway as far as tidy goes, the much bigger problem with it is, it’s using an ad-hoc parser that’s not anywhere even close to conforming to the HTML spec

[14:45:57.0000] <dbaron>
mounir: done

[14:48:40.0000] <MikeSmith>
zcorpan: hmm it just now occurred to me that I may be able to use jsdom/whatwg-url as the URL parser for the HTML checker

[14:49:31.0000] <MikeSmith>
zcorpan: by using the Java8 Nashorn stuff to expose it to the checker Java code

[14:50:59.0000] <MikeSmith>
oh but only if jsdom/whatwg-url emits good errors for syntax violations

[14:53:03.0000] <Sebmaster>
MikeSmith: it does not tell you what's wrong

[14:53:20.0000] <Sebmaster>
only that there is (and slightly more detailed if you use private api)

[14:53:21.0000] <MikeSmith>
Sebmaster: yeah just discovered that from looking at the code :(

[14:53:54.0000] <zcorpan>
mounir: wonder if we should drop the recommendation about clamping to 24? or try to somehow research what the web compat impact would be for returning lower values

[14:54:36.0000] <MikeSmith>
Sebmaster: I think it would be useful to a lot of people if it did emit error messages to the console for the parseError = true cases

[14:55:07.0000] <MikeSmith>
Sebmaster: I thought there was another JS URL parser that did implement error messages

[14:55:48.0000] <Sebmaster>
console is definitely not an option. saving it in the private api might be, but we're currently trying to just very explicitly do what's in the spec so you can put the text next to the code and it lines up perfectly

[14:57:07.0000] <MikeSmith>
well a private API would work fine too

[14:58:30.0000] <MikeSmith>
and I support the design choice of having it explicitly do what’s in the spec so it lines up clearly :)

[14:58:47.0000] <MikeSmith>
makes it much easier to understand the code

[15:01:22.0000] <MikeSmith>
Sebmaster: anyway the code for the HTML checker is in Java but Java8 now has this built-in way to use JavaScript code in Java, so if whatwg-url had a way to emit error messages I could (maybe) use it as the URL parser for the HTML checker

[15:14:06.0000] <Domenic>
I still think the best way to validate URLs is to implement the grammar in the "URL writing" section of the spec

[15:14:10.0000] <Domenic>
That'll be much easier

[15:14:47.0000] <Domenic>
https://url.spec.whatwg.org/#url-writing this would take like an hour

[15:29:29.0000] <mounir>
zcorpan: I can't remember off hand why I campled to 24 but it sounds that it would provide little benefit to give lower values, wouldn't it?

[15:29:45.0000] <mounir>
zcorpan: though, Blink, I believe, would return 2 for BW devices (at least, I think the color MQ does)

[15:29:56.0000] <mounir>
I guess maybe 1 :)

[15:30:23.0000] <zcorpan>
mounir: maybe it was something I suggested ^_^

[15:32:19.0000] <mounir>
zcorpan: happy to drop it

[15:32:33.0000] <mounir>
dbaron: would you be happy with this?

[15:33:05.0000] <dbaron>
mounir: I'd be ok with allowing <24.

[15:40:59.0000] <mounir>
zcorpan, dbaron: updated :)


2017-03-10
[16:20:09.0000] <domfarolino>
What exactly does the reference-implementation in whatwg specs help us do? Is it to help us understand what makes sense and what can be reasonably be implemented? is it often the origin for polyfills?

[16:21:26.0000] <Domenic>
domfarolino: the former. It also helps us write tests.

[16:21:30.0000] <Domenic>
Only streams really does it.

[16:21:38.0000] <Domenic>
jsdom/whatwg-url helps for whatwg/url, but is not official.

[16:23:41.0000] <domfarolino>
Oh yeah it's actually absent most of the time, didn't realize that.

[16:24:40.0000] <terinjokes>
console has tests done another way, but really awkward thing to test

[16:24:44.0000] <terinjokes>
since mostly side effects

[16:31:51.0000] <domfarolino>
gotcha

[18:12:32.0000] <MikeSmith>
Domenic: I guess I could write a separate special URL syntax checker but I use galimatias throughout the HTML checker source for other URL parsing, and its error reporting is pretty good so it’s seemed fine to just rely on that

[18:19:02.0000] <Domenic>
Yeah, hopefully the definition of valid URL doesn't change much

[22:47:20.0000] <annevk>
MikeSmith: yeah, I've asked Sebmaster to expose parse errors

[22:47:41.0000] <annevk>
MikeSmith: https://github.com/jsdom/whatwg-url/issues/61

[22:48:00.0000] <annevk>
MikeSmith: then https://quuz.org/url/uri-validate.html would work again

[22:49:07.0000] <MikeSmith>
cool

[22:49:42.0000] <MikeSmith>
oh I just went to https://github.com/jsdom/whatwg-url/issues/61 to give it a thumbs-up but it says I already did that

[23:10:47.0000] <zcorpan>
https://w3c.github.io/browser-payment-api/#idl-index has trailing commas in idl enums. that's invalid, right?

[23:25:59.0000] <annevk>
zcorpan: no

[23:26:24.0000] <annevk>
zcorpan: pretty sure that was never fixed and I don't think we necessarily should either

[23:27:08.0000] <zcorpan>
annevk: https://heycam.github.io/webidl/#idl-enums i don't see it allowing trailing comma, but maybe I'm missing something

[23:27:48.0000] <annevk>
zcorpan: sorry, I thought you said valid

[23:27:56.0000] <zcorpan>
ah

[23:28:25.0000] <annevk>
zcorpan: haven't had caffeine-free tea yet

[23:29:38.0000] <zcorpan>
annevk: does the tea help?

[23:30:33.0000] <annevk>
zcorpan: can I blame old age?

[23:31:13.0000] <zcorpan>
sure thing :-)

[00:42:53.0000] <annevk>
zcorpan: do we use the compat label also for interop issues?

[00:43:08.0000] <annevk>
zcorpan: I guess we don't really

[00:44:03.0000] <zcorpan>
annevk: don't think so, more compat with web content

[02:30:42.0000] <MikeSmith>
annevk: which part of the UTF-8 decode algorithm in the Encoding spec causes the BOM to be stripped?

[02:31:22.0000] <MikeSmith>
oh

[02:31:51.0000] <MikeSmith>
I guess just step 3

[02:32:02.0000] <MikeSmith>
> If buffer does not match 0xEF 0xBB 0xBF, prepend buffer to stream

[02:33:58.0000] <Ms2ger>
Yep

[02:35:44.0000] <MikeSmith>
thanks

[04:28:01.0000] <annevk>
t.unreached_func cool

[07:24:05.0000] <Sebmaster>
Ooooh. We can just expose an export which returns from the private API. Would that work for you annevk?

[07:25:37.0000] <annevk>
Sebmaster: yeah, I'd be happy to use the private API for that use case

[07:25:56.0000] <annevk>
(I might need some help with regards to how to make that work, but that'd be great to have)

[07:26:09.0000] <annevk>
Then we basically have a Live URL Validator

[07:37:12.0000] <annevk>
When you think software should be decimal-based: https://twitter.com/CodaCoder/status/840205916435705856

[07:49:11.0000] <annevk>
Anyone else having trouble with irc.w3.org?

[07:54:27.0000] <Domenic>
The problem is whatwg-url only implements a random subset of the validation errors

[08:19:45.0000] <astearns>
annevk: I'm not able to connect to irc.w3.org either

[08:29:19.0000] <Ms2ger>
Likewise

[09:48:04.0000] <annevk>
ta

[09:57:43.0000] <annevk>
Anyone interested in reviewing https://github.com/w3c/web-platform-tests/pull/5115? Main blocker to landing standard changes to align all header value separating on ", " (except for CORS, which will not use the space...)

[09:58:35.0000] <annevk>
My go to victims have been Domenic and foolip, but there must be more people out there

[10:00:51.0000] <annevk>
Domenic: ta

[10:01:01.0000] <annevk>
Guess I'll start filing some browser bugs

[10:01:02.0000] <Domenic>
that one was pretty easy :)


2017-03-11
[22:42:08.0000] <MikeSmith>
annevk: when you have some time please look over http://stackoverflow.com/questions/42716082/fetch-api-whats-the-use-of-redirect-manual and consider writing up an answer

[22:42:58.0000] <MikeSmith>
and/or if there’s something I got wrong in the answer I wrote there, please comment to correct it

[22:44:43.0000] <MikeSmith>
or also JakeA ⬆

[22:45:19.0000] <MikeSmith>
studying the https://html.spec.whatwg.org/#navigate algorithm while trying to figure out what the answer to that question is made me realize I really don’t understand that navigate algorithm in the HTML spec at all

[22:45:49.0000] <MikeSmith>
on the face of it, it seems like that algorithm causes a request to be made at least twice

[22:46:30.0000] <MikeSmith>
or I guess maybe I mean more specifically https://html.spec.whatwg.org/#process-a-navigate-fetch

[22:46:38.0000] <MikeSmith>
process a navigate fetch,

[22:47:00.0000] <MikeSmith>
in particular, step 7

[22:47:07.0000] <MikeSmith>
> If response has a location URL and it is either failure or a URL whose scheme is an HTTP(S) scheme, then set response to the result of performing HTTP-redirect fetch using request and response and then run this step again.

[22:48:00.0000] <MikeSmith>
oh I guess that is just for redirects

[22:48:34.0000] <MikeSmith>
but still there’s step 10 there

[22:49:39.0000] <MikeSmith>
ah I mean step 9

[22:49:49.0000] <MikeSmith>
> Otherwise, if response has a location URL that is a URL whose scheme is a fetch scheme, then run process a navigate fetch with a new request whose url is response's location URL, sourceBrowsingContext, browsingContext, and type.

[22:52:00.0000] <MikeSmith>
also as far as need for redirect-mode: 'manual' in the API, I don’t understand the use case at https://github.com/whatwg/fetch/issues/66

[22:54:27.0000] <annevk>
MikeSmith: basically a service worker handling the navigate request

[22:55:26.0000] <annevk>
MikeSmith: does process a navigate fetch set the redirect mode of that request? Otherwise might be a bug

[23:08:17.0000] <MikeSmith>
annevk: well if it doesn’t set it, it just defaults to “follow”, right?

[23:12:29.0000] <annevk>
MikeSmith: yeah but that is wrong

[23:12:54.0000] <annevk>
MikeSmith: navigate should always use mode navigate and manual redirects

[23:13:49.0000] <MikeSmith>
oh

[23:30:36.0000] <annevk>
MikeSmith: anyway, manual is for this case: I navigate to /email

[23:31:23.0000] <annevk>
MikeSmith: service worker fetches, gets a redirect to a mailto URL that it hides through opaqueness and passes that back

[23:31:45.0000] <annevk>
MikeSmith: navigate algorithm then takes action with that

[23:33:27.0000] <MikeSmith>
aha

[23:33:36.0000] <MikeSmith>
yeah I now see the note about that

[13:20:01.0000] <XhmikosR>
MikeSmith: just pinging you about the link color and the validator

[13:24:00.0000] <MikeSmith>
XhmikosR: thanks will try to get a release put together today


2017-03-12
[16:58:48.0000] <MikeSmith>
XhmikosR: I didn’t get the release done over the weekend, will try to make time later this week


2017-03-13
[17:55:26.0000] <IRC-Source_48908>
hey people, i've got a question regarding properly marking up some data, is this the right place to ask or is there somewhere else more suitable for newb questions?

[17:56:40.0000] <MikeSmith>
IRC-Source_48908: best just to ask

[17:57:46.0000] <IRC-Source_48908>
i need to mark this up http://imgur.com/a/1ooJS , but the data is arranged in columns, should I use tables to represent this or something like divs?

[18:03:03.0000] <MikeSmith>
IRC-Source_48908: it looks exactly like tabular data, so it would seem best to mark it up using a <table>

[18:08:54.0000] <IRC-Source_48908>
yea, that's what i thought, as i was marking it up it didn't feel right, the data is only meaningful when you look at it from a column perspective, the rows are meaningless

[18:11:15.0000] <IRC-Source_48908>
or perhaps i should markup each day as it's own table, that would then make sense

[20:45:44.0000] <Domenic>
Hmm the UTF-16 encoder is not specified in encoding.spec.whatwg.org?

[20:46:11.0000] <Domenic>
Someone is claiming that you need to prepend a BOM (in a Node.js issue https://github.com/nodejs/node/issues/11767 ) and that seems wrong but I'm not sure where to confirm...

[23:00:38.0000] <annevk>
Domenic: we removed it since browsers don't need to expose it

[03:13:25.0000] <XhmikosR>
MikeSmith: no worries, it's not so urgent :)

[04:08:33.0000] <annevk>
I wonder why trac.webkit.org is offline for so long

[04:08:43.0000] <annevk>
I guess it's mostly managed by Apple?

[04:11:03.0000] <hsivonen>
what's the motivation for user-select: none; to exist in the Web Platform?

[04:11:10.0000] <hsivonen>
it allows hostile behavior by sites

[04:53:24.0000] <gsnedders>
hsivonen: there are plenty of cases of mouse/touch based navigation where you want to forbid selections, though maybe you can do that decently enough with JS alone, idk

[06:21:15.0000] <hsivonen>
gsnedders: does specifying it on <a> make following links faster in iOS Safari or something?

[06:23:45.0000] <zcorpan_>
hsivonen: i think it is a UI expectation to not allow selection of text in buttons

[06:25:50.0000] <zcorpan_>
e.g. https://dxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css has a bunch of -moz-user-select: none;

[06:53:28.0000] <gsnedders>
hsivonen: I think Google Maps uses it a fair bit, for example

[08:27:31.0000] <topaxi>
its also useful for drag&select style things (like file explorers or desktops)

[08:27:36.0000] <topaxi>
oh i'm very late

[08:27:38.0000] <topaxi>
... :D

[15:15:41.0000] <mounir>
dbaron: any chance you can have a look at https://github.com/w3c/csswg-drafts/pull/994 ? :)

[15:20:11.0000] <dbaron>
mounir: done

[15:21:52.0000] <mounir>
dbaron: thanks :)


2017-03-14
[00:41:09.0000] <zcorpan>
Domenic: re utf-16, iirc, in the era before https://encoding.spec.whatwg.org/ , if the encoding label is "utf-16", the BOM is mandatory; if the encoding label is "utf-16le" or "utf-16be", the BOM is forbidden

[00:43:49.0000] <annevk>
Ah yeah, that sounds about right, but that wasn't actually how anything worked

[01:52:05.0000] <yhirano__>
annevk: Regarding https://bugs.chromium.org/p/chromium/issues/detail?id=580796#c10, do you have any failing tests?

[01:53:03.0000] <annevk>
yhirano__: oh, I forgot to cc myself so I never saw the reply, looking

[01:54:58.0000] <annevk>
yhirano__: I don't have any failing tests

[01:55:31.0000] <yhirano__>
annevk: Thank you, then I will close the issue.

[01:55:49.0000] <annevk>
yhirano__: https://w3c-test.org/cors/redirect-preflight.htm should test the functionality

[01:55:58.0000] <annevk>
yhirano__: I guess that means that only Firefox doesn't implement this yet

[01:58:45.0000] <annevk>
yhirano__: thanks for letting me know

[02:00:11.0000] <yhirano__>
np, and thank you.

[02:00:18.0000] <yhirano__>
annevk: np, and thank you.

[05:29:37.0000] <smaug>
mounir: so about the mousedown/up

[05:31:32.0000] <smaug>
was it really designed so that mouseup isn't supposed to be dispatched at all, even if page got mousedown outside <video>?

[05:31:53.0000] <smaug>
or is that oversight?

[06:07:18.0000] <mounir>
smaug: I couldn't say for sure but likely an oversight

[09:22:04.0000] <ajeffrey_>
A question about https://html.spec.whatwg.org/multipage/browsers.html#dom-history-go...

[09:22:26.0000] <ajeffrey_>
should history.go(0) perform a security check?

[09:22:44.0000] <ajeffrey_>
the spec says it's the same as reload(), which does,

[09:23:17.0000] <ajeffrey_>
but this means that history.go(N) only performs a security check when N=0.

[09:27:14.0000] <annevk>
Is there some sample html5lib treewalker code somewhere I can copy-and-paste from?

[09:28:20.0000] <annevk>
I need to iterate over a bunch of elements parsed from a document, look up some attributes and save the contents of one element, shouldn't be very hard, but with Python I never quite know how to reverse engineer a class

[09:37:40.0000] <Domenic>
ajeffrey_: good question; what do browsers do?

[09:38:05.0000] <gsnedders>
annevk: look at anything in html5lib/filters/

[09:40:16.0000] <ajeffrey_>
Domenic: I realized that was most likely going to be the answer :)

[09:40:28.0000] <ajeffrey_>
I'll test and find out.

[09:41:05.0000] <Domenic>
^_^

[09:45:22.0000] <gsnedders>
annevk: see, e..g, https://github.com/html5lib/html5lib-python/blob/master/html5lib/filters/inject_meta_charset.py

[09:55:47.0000] <ajeffrey_>
Domenic: both FF and chrome actually throw a security exception on any cross-origin history.go(N).

[09:56:38.0000] <ajeffrey_>
we never actually get as far as the spec for go, I suspect.

[09:57:49.0000] <annevk>
Cross-origin how?

[09:58:17.0000] <annevk>
gsnedders: ta, will investigate tomorrow

[09:58:42.0000] <ajeffrey_>
annevk: using iframe.contentWindow on a cross-origin iframe.

[09:59:22.0000] <annevk>
ajeffrey_: history should not be accessible per WindowProxy limitations

[09:59:43.0000] <ajeffrey_>
Domenic: hmm, interestingly FF and chrome disagree about same-origin history.go(0).

[10:00:23.0000] <ajeffrey_>
If you call iframe.contentWindow.history.go(0) in Chrome, it reloads the iframe,

[10:00:36.0000] <ajeffrey_>
in FF it reloads the current document.

[10:01:38.0000] <annevk>
ajeffrey_: then it's not cross-origin or we are missing something

[10:02:02.0000] <annevk>
ajeffrey_: History is not a cross-origin object per standard

[10:02:39.0000] <ajeffrey_>
My read of "When the go(delta) method is invoked, if delta is zero, the user agent must act as if the location.reload() method was called instead." is to reload the currently active document of the window the history came from.

[10:03:22.0000] <annevk>
That only matters if you can access history

[10:03:55.0000] <ajeffrey_>
annevk: yes, this second point is re same-origin history.

[10:05:06.0000] <ajeffrey_>
it's that the spec says "location.reload()" but doesn't actually say which location object to use.

[11:06:25.0000] <annevk>
ajeffrey_: I see, that should probably be refactored

[11:06:42.0000] <annevk>
ajeffrey_: I'm sorry they made you implement this, although I'm also somewhat happy we're getting all the issues logged

[11:13:23.0000] <ajeffrey_>
annevk: np, should I file an issue?

[11:13:34.0000] <annevk>
ajeffrey_: yeah, that's probably best

[11:13:57.0000] <ajeffrey_>
Okay, will do.

[11:16:57.0000] <annevk>
ajeffrey_: if you have any tests those would be good to include btw

[11:20:47.0000] <ajeffrey_>
annevk: OK, I'll see if I can write something.

[11:23:54.0000] <ajeffrey_>
annevk: is there an easy way to check to see if a document is being loaded for the first time vs a reload?

[11:24:44.0000] <annevk>
ajeffrey_: there is some kind of state thing in web-platform-tests, but I'm not familiar enough to give advice

[11:25:15.0000] <ajeffrey_>
annevk: oh yes, I could use a stash.

[11:32:42.0000] <annevk>
ajeffrey_: yes, that thing

[12:20:37.0000] <ajeffrey_>
Submitted https://github.com/whatwg/html/issues/2436


2017-03-15
[01:27:33.0000] <annevk>
A couple of us have been trying to sketch out how the WHATWG operates these days as a potential update to parts of the FAQ

[01:27:35.0000] <annevk>
https://docs.google.com/document/d/199fvmsvdo8HXmPLpdO1sB3tt3y7m-jG0kyqVn32Z6Q4/edit?usp=sharing

[01:27:43.0000] <annevk>
If you have any input that'd be greatly appreciated!

[01:29:00.0000] <annevk>
The goal is to put it up on whatwg.org once everyone is more or less satisfied

[02:18:32.0000] <annevk>
gsnedders: I'm afraid filters/ is not basic enough, I need to do something with the output of the parser

[02:19:46.0000] <annevk>
gsnedders: I might be able to figure something out though

[02:29:07.0000] <annevk>
And I did, hurray, now to actually make this useful...

[02:50:16.0000] <annevk>
Success: https://github.com/w3c/web-platform-tests/pull/5148

[02:53:19.0000] <Ms2ger>
Nice

[02:55:30.0000] <annevk>
Looks like you found the same issue

[02:55:51.0000] <annevk>
potential issue, need zcorpan I guess to confirm

[02:57:32.0000] <zcorpan>
annevk: confirm what?

[02:57:41.0000] <annevk>
zcorpan: see the other review comments

[02:57:47.0000] <annevk>
zcorpan: yours is a good find too

[03:00:00.0000] <annevk>
I also haven't converted tests in subdirectories and there's a fair amount of those

[03:04:27.0000] <Ms2ger>
annevk, I can probably add the variant thing, but not today

[03:04:47.0000] <zcorpan>
Not all of them can be... e.g. cookies/ uses iframe (could maybe be changed to use XHR). unload-a-document/ tests navigation

[03:04:55.0000] <annevk>
Ms2ger: no rush

[03:05:51.0000] <Ms2ger>
File an issue on wpt-tools?

[03:07:15.0000] <annevk>
https://github.com/w3c/wpt-tools/issues/185

[03:09:15.0000] <zcorpan>
"No tests run." :-(

[03:11:25.0000] <annevk>
zcorpan: that's https://github.com/w3c/web-platform-tests/issues/5130

[03:11:45.0000] <Ms2ger>
Do screens for desktops still need a separate power supply these days?

[03:12:06.0000] <annevk>
Ms2ger: I think so

[03:13:10.0000] <annevk>
Ms2ger: those LG monitors Apple sells allow you to do the reverse, drop the power supply for your MacBook (if applicable), haven't seen that elsewhere

[03:13:27.0000] <Ms2ger>
Huh, interesting

[03:17:27.0000] <Ms2ger>
So, 12 power outlets for my office... Would that be enough?

[03:20:36.0000] <annevk>
Ms2ger: I guess that's rhetorical, but if not, if it's just for you, yes

[03:26:44.0000] <jgraham>
Ms2ger: I have four at my dsk here and that isn't enough  :) I also has an extension thing that I remember being broken for some reason and now am scared to plug in

[03:31:34.0000] <annevk>
Yeah, I need 5, but I've got a couple spare still

[05:29:30.0000] <jochen__>
trying to write web-platform-tests for loading images via a stylesheet without falling back to reftests

[05:29:56.0000] <jochen__>
to do that, I'm looking for a way how I could access the actual pixel values from something loaded via a stylesheet

[05:30:10.0000] <jochen__>
however, getComputedStyle(testDiv).backgroundImage only gives me the URL

[05:30:17.0000] <jochen__>
any ideas where to look?

[05:36:37.0000] <MikeSmith>
gsnedders: jgraham ⬆

[05:37:31.0000] <MikeSmith>
wonder if we have existing tests which do something like that

[05:43:59.0000] <annevk>
jochen__: you can't

[05:44:43.0000] <annevk>
jochen__: you could use state on the server though to find out what was requested and how

[06:20:19.0000] <zcorpan>
hsivonen: you may be interested in https://github.com/nodejs/node/issues/11767

[06:25:57.0000] <zcorpan>
jochen__: you could also rely on the (unspecified) fact that background images delay the load event

[06:29:22.0000] <zcorpan>
jochen__: or something like http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4949

[06:30:32.0000] <zcorpan>
(that should wait for onload before checking computed style...)

[06:54:58.0000] <jochen__>
annevk: are there examples of other WPT using server state like that?

[06:55:05.0000] <jochen__>
zcorpan: good idea, thanks!

[06:56:44.0000] <zcorpan>
jochen__: ./html/semantics/document-metadata/the-link-element/stylesheet.py

[06:57:21.0000] <zcorpan>
more examples: grep -rI --exclude-dir=".git" stash .

[06:58:47.0000] <jochen__>
gross. I like it.

[07:52:57.0000] <nox>
Is it me or /html/browsers/the-window-object/security-window/window-security.html is mostly garbage?

[07:53:16.0000] <nox>
Most subtests do not seem to follow the spec, nor to pass in either Safari or Firefox.

[08:33:57.0000] <gsnedders>
nox: if the test is old that's pretty unsurprising

[08:34:05.0000] <nox>
gsnedders: Ok.

[08:34:20.0000] <nox>
gsnedders: TIL cross origin window.alert() is just fine.

[09:24:16.0000] <annevk>
nox: clean it up or file an issue?

[09:33:23.0000] <nox>
annevk: Will do.

[10:46:41.0000] <annevk>
No more legacy bugs for XMLHttpRequest and URL \o/

[10:47:11.0000] <tantek>
annevk++ nice work


2017-03-16
[00:58:10.0000] <mkwst>
tobie: You're in a reasonable time zone, right? :) Do you have a few minutes to help me out with some IDLish questions?

[00:59:37.0000] <Ms2ger>
Morning

[00:59:43.0000] <tobie>
mkwst: I can give it a try.

[00:59:55.0000] <mkwst>
Morning!

[01:00:51.0000] <tobie>
mkwst: I've got a flu, so bear with me if I'm slow at understanding things. :)

[01:00:58.0000] <mkwst>
tobie: I'm trying to do a better job explaining the extension model of https://w3c.github.io/webappsec-credential-management/. Today, it does very hand-wavey things in https://w3c.github.io/webappsec-credential-management/#request-credential (step 5 and beyond).

[01:01:03.0000] <mkwst>
I'd like them to be less hand-wavey.

[01:01:21.0000] <mkwst>
As a short explanation:

[01:02:17.0000] <mkwst>
`get()` accepts a dictionary that specifies what kind of objects the developer wants. `{ type1: true, type2: { long: 'list', of: 'filters' } }`.

[01:03:19.0000] <mkwst>
The current spec converts from the dictionary keys to interfaces more or less by fiat.

[01:03:40.0000] <mkwst>
And then does some weird things about walking the ancestor tree to figure out whether it can service a request for `type1` and `type2` at the same time.

[01:03:56.0000] <mkwst>
And then switches on an interface type, which I'm not sure we can actually do. ;)

[01:04:10.0000] <mkwst>
https://w3c.github.io/webappsec-credential-management/base.html attempts to clarify.

[01:04:53.0000] <mkwst>
https://w3c.github.io/webappsec-credential-management/base.html#credential-internal-methods defines some internal methods on the interface object exposed by the IDL interface.

[01:05:44.0000] <mkwst>
And https://w3c.github.io/webappsec-credential-management/base.html#algorithm-request tries to map the dictionary keys to interfaces by walking the interface objects.

[01:05:53.0000] <mkwst>
step 5ish.

[01:06:06.0000] <mkwst>
(Sorry to everyone else in the channel who's probably not interested. ;) )

[01:08:45.0000] <annevk>
mkwst: you can let IDL handle the initial parsing, and then you need to parse again based on the type parameter

[01:08:58.0000] <annevk>
mkwst: permissions has a similar setup

[01:09:20.0000] <annevk>
mkwst: maybe if enough copycats emerge the whole pattern can be uplifted to IDL somehow

[01:10:28.0000] <annevk>
(Also personally I take interest in all things #whatwg :-p)

[01:12:40.0000] <tobie>
mkwst: sounds like you got all the info you needed and I can go back to sleep.

[01:17:44.0000] <mkwst>
annevk: I'm skimming through the permissions spec. It doesn't seem terribly clear to me.

[01:18:39.0000] <annevk>
mkwst: https://w3c.github.io/permissions/#permissions-interface is the bit I think

[01:18:44.0000] <annevk>
mkwst: I recommend asking jyasskin

[01:18:56.0000] <mkwst>
I'll poke him. Thanks!

[01:34:36.0000] <tobie>
mkwst: if you file an issue somewhere, I'm happy to give it a look too once my cognitive functions are back to normal.

[03:23:03.0000] <MikeSmith>
zcorpan: I don’t understand https://github.com/html5lib/html5lib-tests/issues/89#issuecomment-287013694

[03:24:01.0000] <MikeSmith>
isn’t the “content” string just some internal thing used for html5lib-tests?

[03:24:03.0000] <zcorpan>
MikeSmith: there should be a line `|       content` after <template>

[03:24:17.0000] <MikeSmith>
per spec?

[03:24:33.0000] <MikeSmith>
oh the serializer?

[03:24:44.0000] <MikeSmith>
or what?

[03:25:06.0000] <zcorpan>
well there is no actual spec for this. but i thought part of the point of parsetree was that it could be copy-pasted into html5lib-tests .dat files

[03:25:19.0000] <MikeSmith>
ah

[03:25:28.0000] <MikeSmith>
yeah I guess that’s true

[03:25:42.0000] <MikeSmith>
make sense

[03:25:45.0000] <MikeSmith>
so yeah I can add that

[03:25:57.0000] <zcorpan>
thanks :-)

[03:41:32.0000] <hsivonen>
zcorpan: sad external legacy Windows software is sad

[03:41:54.0000] <hsivonen>
zcorpan: I don't have anything smart to say to the node folks about that

[03:41:57.0000] <hsivonen>
zcorpan: thanks

[03:42:11.0000] <zcorpan>
hsivonen: yeah. i still don't understand why he prefers utf-16 with BOM over utf-8 with BOM, though

[03:42:31.0000] <hsivonen>
zcorpan: does the external legacy thing grok UTF-8 with BOM?

[03:44:20.0000] <zcorpan>
hsivonen: he said that utf-8 without BOM is decoded as "Ansi", but didn't say anything about utf-8 with BOM. It appears he saw the "Unicode" label and decided to stick to that option

[03:44:50.0000] <hsivonen>
zcorpan: I commented after all

[03:45:23.0000] <hsivonen>
/me goes back to removing UTF-16 output capability from Gecko

[03:55:37.0000] <annevk>
zcorpan: pointer to this node issue?

[03:56:04.0000] <zcorpan>
annevk: https://github.com/nodejs/node/issues/11767

[04:00:03.0000] <annevk>
mkwst: we have a few HTTP auth tests for XMLHttpRequest

[04:00:20.0000] <annevk>
mkwst: if you actually remove that functionality those will all have to be adjusted somehow

[04:00:29.0000] <annevk>
mkwst: I'd be somewhat surprised though if nobody relies on it in the wild

[04:01:13.0000] <mkwst>
Hrm?

[04:01:22.0000] <mkwst>
annevk: Sorry, I'm missing context.

[04:02:30.0000] <annevk>
mkwst: I thought you were planning on making the user/password arguments to open() useless

[04:02:47.0000] <annevk>
mkwst: per https://github.com/whatwg/fetch/pull/465

[04:03:18.0000] <annevk>
mkwst: I just posted a web-platform-tests PR fixing some authentication-related tests that uses that functionality, figured I'd let you know

[04:03:23.0000] <mkwst>
Got it, sorry. Yes, I am planning to do that. Yes, it will require adjustments to tests. Yes, it might break things. The metrics look low enough that it's worth trying.

[04:03:49.0000] <mkwst>
Just took me a minute to page that back in, sorry. :)

[04:04:30.0000] <mkwst>
The stable version of Chrome that's rolling out now has a deprecation message in the console for that kind of usage. Let's see who comes at me with pitchforks.

[04:16:57.0000] <hsivonen>
annevk: Mozilla's old tree management tools relied on it. TreeHerder doesn't, IIRC.

[04:26:04.0000] <nox>
zcorpan: Around?

[04:26:14.0000] <zcorpan>
nox: yes

[04:26:44.0000] <nox>
zcorpan: https://github.com/html5lib/html5lib-tests/pull/87/files#diff-80f44ad8658d9cc87ce967f7514ebf8dR227

[04:26:59.0000] <nox>
zcorpan: How come the template element ends up with a plaintext child?

[04:27:18.0000] <zcorpan>
nox: https://github.com/html5lib/html5lib-tests/issues/89

[04:27:33.0000] <nox>
zcorpan: Thanks!

[04:27:38.0000] <nox>
zcorpan: Somehow couldn't find it.

[04:30:40.0000] <MikeSmith>
zcorpan: I am wondering if should I emit “content” even for <template></template>

[04:31:44.0000] <zcorpan>
MikeSmith: https://github.com/html5lib/html5lib-tests/blob/27724be8d27a1232a8809a55f9c37b69706cb03e/tree-construction/template.dat#L33

[04:32:13.0000] <MikeSmith>
ah OK good that makes things easier

[04:32:15.0000] <MikeSmith>
thanks

[04:55:19.0000] <MikeSmith>
zcorpan: https://checker.html5.org/parsetree/?parser=html5&content=%3C%21doctype+html%3E%3Ctemplate%3E%3Cplaintext%3Ea%3C%2Ftemplate%3Eb&submit=Print+Tree

[04:56:11.0000] <zcorpan>
MikeSmith: sweet, thank you

[04:56:35.0000] <MikeSmith>
thanks for the heads-up

[05:08:05.0000] <MikeSmith>
annevk: hsivonen you may find https://github.com/bspammer/vimcryption entertaining

[06:30:42.0000] <annevk>
MikeSmith: heh

[07:25:13.0000] <jochen__>
hum, so this stash thing in wptserve appears to be super unreliable

[07:25:31.0000] <jochen__>
when I load a stylesheet that references and image that stashes something

[07:26:19.0000] <jochen__>
and in the onload handler for the stylesheet (after checking via getComputedStyle to make sure the image was really loaded), and load the image via an xhr again, every few tries, it can't find anything stashed in the server

[07:33:46.0000] <zcorpan>
jgraham: ^

[07:34:35.0000] <jgraham>
jochen__: Can you make a testcase for me to look at? We have some tests using it that I don't think are unreliable, but it could be broken

[08:27:10.0000] <jyasskin>
mkwst: Sorry permissions wasn't clear.

[08:27:29.0000] <mkwst>
jyasskin: Sorry I'm dumb! :)

[08:28:01.0000] <mkwst>
It looks like it's binding things to strings, and it's just not clear to me how that's expected to work from a spec perspective.

[08:28:09.0000] <mkwst>
But I read it quickly, so I likely missed something important.

[08:29:50.0000] <jyasskin>
mkwst: Permissions says, here's a mapping of strings to dictionary types. The mapping is held in the base standard, but the dictionaries may be defined in the extension standards.

[08:30:43.0000] <jyasskin>
mkwst: That's to make it easier to read: you don't have to divine the entire universe of extensions to understand the code. You have the whole set in one place.

[08:31:20.0000] <jyasskin>
i.e. "the set of interfaces whose inherited interfaces contain Credential." is a clever way to do the same thing, but I think it'll make the spec harder to follow.

[08:31:26.0000] <jochen__>
jgraham: https://github.com/w3c/web-platform-tests/pull/5160

[08:32:03.0000] <jyasskin>
The downside of the Permissions approach is that we have to keep updating the core spec, which is less compatible with the W3C's processes.

[08:32:08.0000] <mkwst>
jyasskin: In my head, it's simpler, because it's pointing at concepts that exist in IDL, and I wanted to avoid making the spec a registry.

[08:32:10.0000] <mkwst>
Right, that.

[08:33:28.0000] <jyasskin>
I think your wording is effective, but it's a COMEFROM label, which I try to avoid. :)

[08:34:39.0000] <jyasskin>
mkwst: Also, today's my day off for baby care, so I'll be around irregularly.

[08:34:55.0000] <jochen__>
eh, if intercal can do it, it's ok

[08:35:18.0000] <mkwst>
jyasskin: I guess I see it as an implicit registry, but I totally get that it's confusing (and I'm not sure I'm using the right IDL language anyway).

[08:35:43.0000] <mkwst>
jyasskin: Also also, go take care of a baby! They're cuter than me and need more attention. :)

[08:36:22.0000] <jyasskin>
We don't have a *good* way to do registries yet, so each author gets to pick their least-bad way.

[08:41:16.0000] <jgraham>
jochen__: OK, ,I'll take a look. Thanks

[09:15:25.0000] <jgraham>
jochen__: /referrer-policy/css-integration/external-stylesheet.html doesn't exist in that PR?

[09:16:09.0000] <jochen__>
meh

[09:35:56.0000] <jochen__>
jgraham: updated the PR

[10:03:29.0000] <jgraham>
jochen__: Isn't the problem here just that images aren't critical subresources of stylesheets

[10:03:55.0000] <jgraham>
So when the load event fires the image hasn't necessarily put anything in the stash yet

[10:04:02.0000] <jgraham>
So your test is racy?

[10:04:10.0000] <jochen__>
if you look at the console output, you'll see that the heightof the background-image is known before I even start the XHR

[10:04:42.0000] <jochen__>
that means that the part of image.py the stashes (which happens before I even generate the image) should have completed

[10:09:05.0000] <jgraham>
jochen__: And yet the logging I have shows

[10:09:06.0000] <jgraham>
Took data from stash

[10:09:06.0000] <jgraham>
application/json

[10:09:06.0000] <jgraham>
Put data in stash

[10:09:06.0000] <jgraham>
Generated image

[10:09:12.0000] <gsnedders>
jochen__: that only means it knows the height of the div, not that it has loaded or painted the image

[10:09:50.0000] <jgraham>
Right, it's probably telling you your font size * line height

[10:11:24.0000] <gsnedders>
the computed height of the div is totally unrelated to the image I'm pretty sure

[10:11:31.0000] <jochen__>
hum

[10:11:39.0000] <jochen__>
zcorpan suggested to use that :)

[10:12:06.0000] <jochen__>
is there a good way to wait for the image to be loaded?

[10:12:21.0000] <jgraham>
I agree that gives you a good prior, but even zcorpan is wrong occasionally (it is rumored)

[10:12:22.0000] <gsnedders>
/me isn't entirely sure about behaviour around `content` property here

[10:12:49.0000] <jgraham>
Well and ::before is an extra layer of complexity

[10:12:50.0000] <gsnedders>
so the content property makes it a replaced element, but pending the load of the image it has no intrinsic width/height

[10:13:34.0000] <gsnedders>
so, uh, idk

[10:14:34.0000] <jgraham>
Anyway the server logs don't support the idea that the loads happen in the order you think

[10:23:45.0000] <annevk>
This is where you use test.step_yolo

[10:23:51.0000] <annevk>
I mean test.step_timeout

[10:26:07.0000] <jgraham>
test.make_intermittent would have been a good and accurate name

[10:27:02.0000] <annevk>
test.step_on_jugglinmike

[14:45:49.0000] <Domenic>
What the what https://bugs.webkit.org/show_bug.cgi?id=25893

[14:45:56.0000] <Domenic>
(tales from the crypt of time)

[15:26:40.0000] <noah>
annevk: food for thought, maybe... we have this new library for parsing and canonicalizing urls, and one of the things it does is pull apart parsing and canonicalization into separate steps... i wonder if you think that might be a good idea for the whatwg spec, or if conversely there's some reason why that approach is incorrect

[15:26:47.0000] <noah>
see https://github.com/iipc/urlcanon/blob/master/python/urlcanon/parse.py and https://github.com/iipc/urlcanon/blob/master/python/urlcanon/canon.py

[16:43:31.0000] <JakeA>
annevk: Is there anything particular you want us to tackle at the service worker f2f in terms of fetch? I'm going to 'present' the fetch control/cancelation stuff.


2017-03-17
[17:18:25.0000] <wanderview>
JakeA: its possible we could have an initial implementation of that in nightly for the meeting

[17:23:35.0000] <wanderview>
I just need to review the patches in here: https://bugzilla.mozilla.org/show_bug.cgi?id=1341738

[17:58:10.0000] <TabAtkins>
annevk: Just FYI, I saw your pings, but was busy all day working with fantasai, and am about to be gone for a week. I'll get back to you on or soon after the 27th.

[18:14:53.0000] <JakeA>
wanderview: fetch cancellation? Oh wow, that'd be ace

[18:15:13.0000] <wanderview>
yea

[18:15:21.0000] <wanderview>
baku already wrote it... I just have to find the time to review it

[18:16:55.0000] <wanderview>
JakeA: are you still on holiday?

[18:18:45.0000] <JakeA>
wanderview: half and half. I've been working this week but off next week

[18:19:34.0000] <wanderview>
cool

[18:21:23.0000] <wanderview>
JakeA: I was thinking maybe we could do a "what have we been doing in the last 6 months" segment

[18:21:41.0000] <wanderview>
JakeA: to give some context about what each team has been focusing on and is probably going to focusing on in near future

[18:30:11.0000] <JakeA>
wanderview: that's a great idea. Will ask our team to do the same

[22:03:53.0000] <annevk>
JakeA: there was some other issue I pointed out

[22:04:21.0000] <annevk>
JakeA: exposing sw mode

[01:33:41.0000] <jochen__>
annevk: why is createProcessingInstruction() on an HTMLDocument supported?

[01:34:48.0000] <annevk>
jochen__: probably because restricting it is rather meaningless?

[01:37:32.0000] <jochen__>
hum, according to mdn it used to be restricted to XMLDocuments

[01:38:09.0000] <annevk>
jochen__: I think that's true, but I think we removed the restriction because the restriction doesn't actually restrict anyone from creating one

[01:39:37.0000] <annevk>
jochen__: looks like it was changed six years ago: https://github.com/whatwg/dom/commit/7c03f8dff921371e36b755cbb6370eea6a0e8a37

[01:40:13.0000] <annevk>
jochen__: unfortunately we didn't file bugs for all implementations back then

[01:41:07.0000] <jochen__>
seems to work in blink :)

[01:41:35.0000] <annevk>
jochen__: so just MDN that's wrong then?

[01:54:55.0000] <annevk>
mkwst: you never got back to me in https://github.com/w3c/web-platform-tests/pull/2356

[01:55:27.0000] <mkwst>
Wow. That's an old PR.

[01:55:35.0000] <mkwst>
I'll take a look.

[02:00:46.0000] <KiChjang>
does anyone know why script tags MUST have a </script> closing tag in order to properly close it?

[02:01:33.0000] <KiChjang>
i hear that if you do something like <script src="..." /> in some browsers, anything that goes after it would be treated as inline JS until the next </script> tag is encountered

[02:02:14.0000] <KiChjang>
that doesn't sound like intended behaviour to me, or is this actually specc'd out?

[02:02:20.0000] <annevk>
KiChjang: /> is a thing invented by XML that HTML didn't support until it got support for inline SVG and MathML and then it only supported it there

[02:02:48.0000] <annevk>
KiChjang: the HTML parser is very much specified in detail

[02:03:43.0000] <annevk>
mkwst: I'm cleaning up web-platform-tests a bit and that includes my own forgotten stuff

[02:06:11.0000] <KiChjang>
annevk, ah, so the self-closing tag on script didn't follow XML semantics?

[02:06:35.0000] <annevk>
KiChjang: I'm not sure what that means

[02:07:22.0000] <KiChjang>
i'd expect that a self-closing script tag (<script src="..." />) would not treat anything after it as inline JS

[02:08:06.0000] <annevk>
KiChjang: again, HTML doesn't have self-closing tags, apart from the SVG and MathML islands which are very much contained

[02:08:44.0000] <KiChjang>
wait if that's so, then this syntax is actually invalid HTML?

[02:09:10.0000] <annevk>
KiChjang: yes

[02:09:18.0000] <KiChjang>
/me mindblown

[02:09:52.0000] <annevk>
KiChjang: you can use it on void elements, e.g., <img/>

[02:10:01.0000] <annevk>
KiChjang: but not on arbitrary elements

[02:10:25.0000] <annevk>
KiChjang: and we only allow it on void elements because of the XHTML craze in the 00s

[02:11:16.0000] <KiChjang>
did <br> became a void element just because of this?

[02:11:26.0000] <KiChjang>
i think i recall it not being one before

[02:11:34.0000] <annevk>
It was always a void element

[02:11:41.0000] <annevk>
What changed is that it's now valid to write <br/>

[02:12:14.0000] <annevk>
(It also used to have a different name from void element, just an element without end tag I think, but that doesn't matter much)

[02:18:46.0000] <KiChjang>
it's kinda surprising how everything i learnt lately about HTML tags are actually all wrong

[02:19:18.0000] <annevk>
Maybe you're reading books from the early 00s?

[02:19:19.0000] <KiChjang>
i do recall that back during 00s, closing tags must always be written in HTML

[02:19:40.0000] <KiChjang>
it's sometime in the future it became unnecessary and /> was the new syntax that everyone was going for

[02:20:07.0000] <annevk>
That was the XML dream that never panned out

[02:20:53.0000] <KiChjang>
yes, i remember reading something that says you need to specify the HTML document version before the <head> tag

[02:21:08.0000] <KiChjang>
and if you want XHTML, you also need to specify it and its version

[02:21:22.0000] <KiChjang>
looks like we've come a long way just to use HTML again

[02:21:36.0000] <annevk>
version?

[02:21:45.0000] <KiChjang>
yes, 1.0 IIRC

[02:21:52.0000] <annevk>
KiChjang: https://annevankesteren.nl/2007/04/html-red-pill

[02:22:18.0000] <KiChjang>
ah, i'm talking about during the XHTML craze

[02:22:36.0000] <annevk>
ah

[02:22:37.0000] <KiChjang>
wasn't that the case?

[02:23:01.0000] <annevk>
Yeah, you'd have the 1.0 or 1.1 DOCTYPE

[02:23:07.0000] <annevk>
And then it could be transitional or strict

[02:23:20.0000] <KiChjang>
lol this brings back memories

[02:23:27.0000] <annevk>
And all kinds of other nonsense that didn't actually have a meaningful processing model attached to it

[02:23:30.0000] <KiChjang>
i never figured out the difference between trasitional and strict

[02:23:47.0000] <annevk>
KiChjang: comes down to https://quirks.spec.whatwg.org/ mostly

[02:53:56.0000] <nox>
Should reparented text nodes be coalesced when parsing?

[02:55:17.0000] <nox>
Let me check if the test mentioned in https://github.com/servo/servo/issues/15979 passes in Firefox...

[05:54:36.0000] <mkwst>
Does HTML expose a concept of "active" browsing contexts? That is, I would like to say something about the tab a user is interacting with, and not the thirtieth tab on a background window the user forgot they'd opened.

[06:32:43.0000] <wanderview>
mkwst: I was going to say you could use the has-focus-steps... but I think they are busted atm

[06:35:13.0000] <mkwst>
Step 1 of https://html.spec.whatwg.org/#has-focus-steps talks about "the top-level browsing context". Which top-level browsing context?

[06:36:12.0000] <wanderview>
mkwst: right... it incorrectly says any top level window has focus

[06:36:19.0000] <wanderview>
I think JakeA wrote an issue against it

[06:36:46.0000] <mkwst>
wanderview: Got it.

[06:36:55.0000] <wanderview>
https://github.com/whatwg/html/issues/2391

[06:37:26.0000] <wanderview>
of course we still have stuff depending on this algorithm

[06:37:50.0000] <wanderview>
in service workers clients.matchAll() is intended to be ordered such that windows most recently interacted with are first

[06:38:36.0000] <mkwst>
I see. I guess from a practical perspective, this seems like the right algorithm to reference, and I can just assume that annevk, et al will fix it up? :)

[06:39:15.0000] <wanderview>
probably

[06:39:39.0000] <annevk>
Hmm, if you have bandwidth apart from coming up with Q1 goals that'd be great

[06:40:26.0000] <mkwst>
I still have a good ~2 weeks to come up with my plans for Q1.

[08:58:45.0000] <annevk>
If anyone fancies reviewing Infra PRs, I put up a bunch

[09:10:04.0000] <annevk>
Thanks mkwst! Will reply to the rest later today most likely, gotta collect the kid and food

[09:10:18.0000] <mkwst>
No worries! Thanks for your work!

[10:18:56.0000] <Domenic>
Posted https://github.com/tabatkins/bikeshed/issues/958 (/cc zcorpan)

[10:19:10.0000] <Domenic>
annevk: excited to review infra PRs, I was just thinking yesterday how it needed a bit more love

[10:20:02.0000] <annevk>
Domenic: four PRs left

[10:20:33.0000] <annevk>
Domenic: I guess you're correct about label research, probably often it can be solved by using a different "function" instead as well

[10:21:08.0000] <Domenic>
Yeah, although that's generally an area where specs do less breaking things into functions than software does... not sure exactly why though

[10:26:33.0000] <annevk>
Domenic: maybe no labels indeed: http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

[10:27:21.0000] <annevk>
Domenic: perhaps in part standards do that to avoid having other standards rely on what they consider internal methods

[10:27:39.0000] <Domenic>
Ah that's an interesting point

[10:27:41.0000] <annevk>
Domenic: we don't really have a good public/private API story for standards

[10:28:24.0000] <annevk>
Domenic: the "host" convention from JavaScript doesn't really work for us I think

[10:30:37.0000] <Domenic>
Agreed, and that isn't really quite solving the same problem

[10:31:01.0000] <Domenic>
I'm not sure what an unobtrusive convention could be

[10:31:17.0000] <Domenic>
I'm thinking like a little "E" box next to the <dfn> or something? I dunno.

[10:35:24.0000] <annevk>
Domenic: maybe we should mark public DFNs green?

[10:35:36.0000] <Domenic>
ooh color that might work...

[10:35:39.0000] <annevk>
Domenic: just like headers

[10:36:13.0000] <annevk>
Domenic: and we just tag them somehow, we don't base it off export, since there's often folks wanting to refer to private stuff anyway

[10:37:38.0000] <Domenic>
wait why wouldn't we base it off export?

[10:39:44.0000] <annevk>
Domenic: I'm not sure if it happens just with monkey patches, but for those you often want to refer to things that you'd not normally consider a public API

[10:40:26.0000] <annevk>
Domenic: the other example is CSP explaining how it interleaves with various sub-fetch algorithms such as HTTP-network fetch that shouldn't be invoked on their own

[10:40:50.0000] <annevk>
So yeah, that's why you sometimes want to export private entry points

[10:42:40.0000] <Domenic>
Hmm

[10:42:46.0000] <Domenic>
I'd maybe make that opt-out

[10:42:54.0000] <Domenic>
E.g. <dfn export notpublic>

[10:44:14.0000] <annevk>
Seems reasonable

[10:44:32.0000] <annevk>
We should probably do it through Bikeshed since you want some kind of title attribute generated as well, so it's at least somewhat accessible


2017-03-18
[02:15:17.0000] <annevk>
SimonSapin: you might find https://github.com/whatwg/infra/pull/73 interesting

[02:15:29.0000] <annevk>
tobie: https://github.com/whatwg/infra/pull/73

[02:18:21.0000] <SimonSapin>
annevk: nice

[13:03:50.0000] <domfarolino>
Domenic: with issues like https://github.com/whatwg/console/issues/89 that involve adding functionality to browsers + spec, is it best to just @mention implementers and get their thoughts/spark conversation? I assume so

[13:38:20.0000] <Domenic>
domfarolino: yeah that's generally the way to go. It seems like every browser has at least one person involved in the issues there, which is great.

[13:38:37.0000] <Domenic>
domfarolino: personally I think https://github.com/whatwg/console/issues/27 is the next high-impact bug for console

[13:40:13.0000] <Domenic>
https://github.com/whatwg/console/issues/84 is also interesting

[13:56:32.0000] <domfarolino>
Gotcha, thanks


2017-03-19
[07:01:30.0000] <JosephSilber>
TabAtkins, Grid question: when using dynamic column gap sizes (via justify-content: space-around or space-between), is there any way to have the row gaps' size match the columns' gaps?

[07:22:24.0000] <annevk>
JosephSilber: he's away per Twitter

[07:32:28.0000] <JosephSilber>
Thanks.

[10:00:58.0000] <TabAtkins>
Tho I have plenty of Internet when we're in port, surprisingly.

[10:00:58.0000] <TabAtkins>
JosephSilber: No, there isn't.

[12:31:50.0000] <billy-woods>
hi all. github newbie here, and i want to make sure i'm doing the right thing! domenic opened an issue labelled 'good first bug' recently (https://github.com/whatwg/html/issues/2446). am i right in thinking that i need to (1) fork the repo, (2) modify the file called "source" as appropriate in my own forked copy, (3) submit a pull request back to the main

[12:31:51.0000] <billy-woods>
repo, and that's it? thanks

[12:38:23.0000] <annevk>
billy-woods: yup, ta!

[12:39:19.0000] <billy-woods>
okay, great. will give it a go now (+ also trying out building a local copy) and get back to you if i struggle. :)

[12:50:58.0000] <annevk>
billy-woods: hopefully someone else can help you then, bit late here

[12:51:24.0000] <billy-woods>
no problem, thanks for your replies anyway :)

[12:52:46.0000] <Domenic>
I've got a haircut starting about now but should be able to answer questions after the next hour or so :).

[13:13:44.0000] <billy-woods>
i confused myself a couple of times along the way, but i think i've sent a pull request now :)


2017-03-20
[01:13:41.0000] <annevk>
zcorpan: technically https://github.com/whatwg/html/pull/2449 was not editorial, existing text would result in a compile error I think

[01:17:01.0000] <annevk>
I do like your use of the Unicode arrow, I should try to find it next time I have something like this

[02:03:25.0000] <felixjet>
can someone give me a hand?

[02:03:29.0000] <felixjet>
the validator is trolling me

[02:03:40.0000] <felixjet>
Error: Element pre not allowed as child of element figure in this context.

[02:04:01.0000] <felixjet>
Contexts in which element pre may be used: --> Where flow content is expected.

[02:04:14.0000] <felixjet>
right. so i can only use <pre> where flow content is expected

[02:04:29.0000] <felixjet>
Content model for element figure: --> Flow content optionally including a figcaption child element.

[02:04:34.0000] <felixjet>
so..... wt*

[02:04:45.0000] <felixjet>
figure accepts flow content

[02:04:53.0000] <felixjet>
and <pre> must be used where flow content is expected

[02:04:57.0000] <felixjet>
whats going wrong here?

[02:10:33.0000] <annevk>
felixjet: I'd file a bug

[02:10:46.0000] <felixjet>
so i have nothing wrong here?

[02:10:53.0000] <felixjet>
in case it matters

[02:10:55.0000] <felixjet>
my structure is:

[02:11:11.0000] <felixjet>
<figure><div></div><figcaption></figcaption><pre></pre></figure>

[02:11:18.0000] <felixjet>
maybe i can't use div AND pre?

[02:11:33.0000] <felixjet>
but the spec doesn't say anything about how many flow content elements are valid

[02:11:47.0000] <MikeSmith>
the spec says that’s not valid

[02:11:55.0000] <MikeSmith>
https://html.spec.whatwg.org/multipage/semantics.html#the-figure-element

[02:12:03.0000] <MikeSmith>
Content model:

[02:12:03.0000] <MikeSmith>
Either: One figcaption element followed by flow content.

[02:12:03.0000] <MikeSmith>
Or: Flow content followed by one figcaption element.

[02:12:03.0000] <MikeSmith>
Or: Flow content.

[02:12:08.0000] <felixjet>
it just say:

[02:12:12.0000] <felixjet>
Content model: -> Either: One figcaption element followed by flow content.

[02:12:30.0000] <MikeSmith>
which spec?

[02:12:35.0000] <felixjet>
whatwg

[02:12:49.0000] <felixjet>
i just copied what you just said

[02:12:58.0000] <felixjet>
so <div></div><pre></pre> is not "flow content" ?

[02:13:17.0000] <MikeSmith>
<div></div><figcaption></figcaption><pre></pre> is not One figcaption element followed by flow content

[02:13:35.0000] <felixjet>
why the order does matter?

[02:13:39.0000] <MikeSmith>
that is flow content followed by figcaption followed by flow content

[02:13:45.0000] <felixjet>
what if figcaption is in the middle?

[02:13:51.0000] <MikeSmith>
yeah, that

[02:13:52.0000] <felixjet>
i mean, why thats now allowed?

[02:13:57.0000] <felixjet>
not*

[02:14:02.0000] <MikeSmith>
because that is what the spec requires

[02:14:31.0000] <felixjet>
but maybe is spec'ed like that because none was thinking about using multiple flow content inside figure

[02:14:38.0000] <felixjet>
but there shouldn't be any limitation to do so

[02:14:41.0000] <felixjet>
technically

[02:14:43.0000] <felixjet>
i'm wrong?

[02:15:02.0000] <MikeSmith>
it was specified that way intentionally, it is not an oversight

[02:15:38.0000] <MikeSmith>
the intent is just that the figcaption must be either the first child of the figure or the last child

[02:16:02.0000] <felixjet>
i was using the div to create a title, the figcaption to describe the figure, and <pre> is the figure itself

[02:16:21.0000] <felixjet>
but <figcaption><div><pre> is allowed?

[02:16:28.0000] <MikeSmith>
yup

[02:16:33.0000] <felixjet>
so... why in me middle is forbidden?

[02:16:38.0000] <felixjet>
in the*

[02:16:45.0000] <felixjet>
theres a real reason?

[02:16:54.0000] <MikeSmith>
because as I said, the intent is just that the figcaption must be either the first child of the figure or the last child

[02:17:08.0000] <felixjet>
yeah, i realize thats the intent

[02:17:09.0000] <felixjet>
but why?

[02:17:33.0000] <felixjet>
is there a real reason behind than?

[02:17:37.0000] <MikeSmith>
yes

[02:17:38.0000] <felixjet>
rather than "its how it is"

[02:17:42.0000] <annevk>
I haven't really encountered a figure with a caption in the middle

[02:17:45.0000] <MikeSmith>
because the rest of the content is the figure

[02:17:56.0000] <MikeSmith>
right, what annevk said

[02:18:06.0000] <felixjet>
so even if figcaption is in the middle, the rest of the content can be the figure too

[02:18:08.0000] <felixjet>
:/

[02:18:20.0000] <felixjet>
just like if you use <figcaption><pre><div><whatever>

[02:18:33.0000] <felixjet>
in this example, those 3 tags are the flow content

[02:18:38.0000] <annevk>
felixjet: if you have a good use case (bit more fleshed out than these markup examples) it might be worth filing a bug against the HTML Standard

[02:18:49.0000] <felixjet>
but <div><whatever><figcaption><pre>, it can not be?

[02:18:54.0000] <annevk>
felixjet: it's not unchangeable

[02:19:18.0000] <felixjet>
yeah, wanted to get some feedback then, in case there is a technical reason behind it

[02:20:15.0000] <MikeSmith>
the technical reason is that when as user looks at your figure, how to they tell what part of it is the caption?

[02:20:29.0000] <felixjet>
the <figcaption>

[02:20:48.0000] <felixjet>
and the rest is the figure

[02:20:53.0000] <MikeSmith>
how do users know what part is the figcaption?

[02:21:01.0000] <MikeSmith>
they don’t look at the source

[02:21:08.0000] <MikeSmith>
they look at how it is rendered

[02:21:39.0000] <felixjet>
how users know if the main content is a <main> tag, or just a <div>?

[02:21:42.0000] <MikeSmith>
and what users expect to see is a caption either above the figure or below the figure

[02:21:48.0000] <felixjet>
if they don't look at the source

[02:21:51.0000] <felixjet>
they just don't know

[02:22:13.0000] <MikeSmith>
sure they do, in teh case of figcaption

[02:22:14.0000] <felixjet>
the figure caption describes the figure

[02:22:36.0000] <felixjet>
so, the description, is the figcaption

[02:22:42.0000] <MikeSmith>
yeah

[02:22:52.0000] <felixjet>
i think people will know what a description is

[02:23:03.0000] <MikeSmith>
for users, the caption for a figure is either some text that is rendered just above the figure or just after the figure

[02:23:08.0000] <felixjet>
for example (maybe this is a retarded example, so sorry if it is)

[02:23:34.0000] <MikeSmith>
regardless of how it is marked up in the source, users look for the text before the figure or after the figure

[02:24:10.0000] <felixjet>
<figure><img src="duck.jpg"><figcaption>A duck dancing in the river</figcaption><time>2011-11</time></figure>

[02:24:19.0000] <felixjet>
what describes the figure? the figcaption of course

[02:24:23.0000] <felixjet>
and the time doesn't describe anything

[02:24:27.0000] <felixjet>
is not a description

[02:24:34.0000] <felixjet>
but it's part of the figure

[02:24:45.0000] <felixjet>
the picture and the time are related

[02:24:54.0000] <felixjet>
so why don't let people wrap that in a <figure>?

[02:24:56.0000] <felixjet>
to me, it makes sense

[02:25:28.0000] <MikeSmith>
I don’t understand how the <time> is part of the figure in that example

[02:25:36.0000] <felixjet>
and makes even more sense if you are using a div to apply styles

[02:26:09.0000] <felixjet>
which makes the figure a "figcaption followed by 1 flow content"

[02:26:29.0000] <felixjet>
MikeSmith, the time could be the date when the photo was taken

[02:26:41.0000] <felixjet>
it doesn't describe the photo

[02:26:46.0000] <felixjet>
so it can't be a caption

[02:27:09.0000] <MikeSmith>
seems like it does describe the photo actually

[02:27:19.0000] <MikeSmith>
but anyway as annevk said, if you think the spec should change you should raise an issue at https://github.com/whatwg/html/issues

[02:27:27.0000] <felixjet>
a description is a description in my opinion

[02:27:33.0000] <felixjet>
a date doesn't describe a duck

[02:27:54.0000] <felixjet>
but "the yellow duck dances by the river" is a description of the photo

[02:28:16.0000] <felixjet>
i'll file an issue so people can discuss

[02:28:21.0000] <MikeSmith>
in that example I don’t see how a user is supposed to know that 2011-11 means when the photo was taken

[02:28:35.0000] <felixjet>
Well, it was en example

[02:28:40.0000] <felixjet>
instead of <time>

[02:29:03.0000] <felixjet>
it could be: <div>Photo taken: <time>...</time></div>

[02:29:14.0000] <MikeSmith>
if/when you raise an issue I think you want to have a real example, a real use case

[02:29:54.0000] <felixjet>
my use case is really weird that probably someone will complain that is too retarded

[02:30:22.0000] <felixjet>
to me it makes sense ofc, but probably for others i'm missusing the tag

[02:30:44.0000] <MikeSmith>
well it may be odd but the spec is intended to cover odd use cases too if they are valid

[02:30:48.0000] <felixjet>
i'm using a <div> to indicate an API endpoint URL

[02:30:56.0000] <felixjet>
the figcaption to describe the figure

[02:31:08.0000] <felixjet>
and a <pre> tag to show the output of the API call

[02:31:18.0000] <felixjet>
the figcaption describes both the div and the pre tag

[02:31:20.0000] <MikeSmith>
btw please consider not using the word “retarded” the way you have been here. It’s an offensive term

[02:31:47.0000] <felixjet>
sorry, i use it as "stupid"

[02:31:58.0000] <MikeSmith>
so if that is your real use case then please include those details in the issue

[02:38:18.0000] <felixjet>
anyway, the spec also says

[02:38:21.0000] <felixjet>
> The figcaption element represents a caption or legend for the rest of the contents of the figcaption element's parent figure element, if any.

[02:38:29.0000] <felixjet>
"rest of the contents"

[02:38:30.0000] <felixjet>
thats plural

[02:39:01.0000] <felixjet>
figcaption being in the middle, could also mean that above, and below figcaption, all is related to the figure

[02:39:18.0000] <felixjet>
(just as an idea)

[02:40:21.0000] <annevk>
felixjet: I think though that if you use <time> in that way the <figcaption> wouldn't say anything about the <time>

[02:40:35.0000] <annevk>
felixjet: both <figcaption> and <time> would say something about the figure

[02:41:55.0000] <felixjet>
thats a good argument

[02:42:23.0000] <felixjet>
but only the first one

[02:42:50.0000] <felixjet>
not the second, since the time doesn't represent whats inside the picture at all

[02:45:02.0000] <felixjet>
but anyway i can't argue now hahga

[02:45:08.0000] <felixjet>
you have a point

[02:46:16.0000] <felixjet>
damn, you could have said it before, i have 90% of the issue done xD

[02:46:23.0000] <felixjet>
problem solved i guess, thanks

[02:49:54.0000] <annevk>
felixjet: allowing that would still require changes, so might as well file the issue

[02:58:21.0000] <felixjet>
how i'm supposed to file an issue without an example now >.<

[02:58:49.0000] <annevk>
felixjet: it's still a valid example

[02:58:58.0000] <annevk>
felixjet: since it still fails validation and maybe should not

[03:03:50.0000] <annevk>
I wonder if https://github.com/whatwg/html/issues/2441 is the first time Jens commented on a standard

[03:06:46.0000] <felixjet>
filed: https://github.com/whatwg/html/issues/2450

[03:13:15.0000] <felixjet>
the <credit> one is a great argument in favor of sparse flow content

[03:21:24.0000] <MikeSmith>
oh wow jl

[03:23:34.0000] <MikeSmith>
felixjet: thanks for taking time to file that issue. Great issue description

[03:24:20.0000] <felixjet>
thank you for taking the time to give feedback :)

[04:00:07.0000] <zcorpan>
Using the string "null" as an origin was maybe not the greatest idea. See https://labs.detectify.com/2017/02/28/hacking-slack-using-postmessage-and-websocket-reconnect-to-steal-your-precious-token/ section Mitigation

[04:26:01.0000] <MikeSmith>
zcorpan: I think we should fix that by changing the CORS protocol so that a null origin never matches anything, equality comparison always fails

[04:26:49.0000] <MikeSmith>
the WebAppSec CORS section mentioned something about maybe the protocol will eventually change, so don’t rely on null matching forever

[04:26:55.0000] <zcorpan>
MikeSmith: CORS is not involved in window.postMessage

[04:27:28.0000] <MikeSmith>
ah hadn’t read the article yet :)

[04:27:36.0000] <MikeSmith>
as postMessage

[04:28:16.0000] <MikeSmith>
*ah it includes more and

[04:28:18.0000] <MikeSmith>
ofofs

[04:28:37.0000] <MikeSmith>
/me gives up on trying to type coherently for now

[04:55:35.0000] <mkwst>
zcorpan: It's doing a string comparison against "null", right? If so, it's not clear to me how they'd 'accept messages from the origin "null".'

[04:56:23.0000] <zcorpan>
mkwst: it doesn't

[04:56:32.0000] <zcorpan>
mkwst: it does if (!url)

[04:57:07.0000] <zcorpan>
which is probably dead code

[04:57:35.0000] <mkwst>
Ah. Yeah. That's not going to work.

[04:58:04.0000] <mkwst>
I see. `a.src = "null"` resolves against the local document, which breaks their comparison.

[04:59:07.0000] <mkwst>
Well, I wouldn't be terribly sad if we changed postmessage to send `null` rather than `"null"`, but I suspect that's going to be difficult to change at this point.

[05:00:09.0000] <zcorpan>
changing it would introduce a problem for anyone who checks for the string "null"

[05:00:36.0000] <mkwst>
Exactly.

[07:54:04.0000] <annevk>
mkwst: just keep saying no to versioning btw, even if a bunch of folks tell you it's a good idea

[07:54:38.0000] <mkwst>
Yeah, I think the costs are pretty high.

[07:56:20.0000] <annevk>
We're still cleaning up the last time browsers decided to add a giant branch in their code

[07:57:43.0000] <mkwst>
I'll ping you if people say they totally need it.

[07:57:55.0000] <mkwst>
Until then, I'm not actually planning on ever writing a CSP4, so...

[08:02:17.0000] <annevk>
You'll have to keep maintaining CSP though, but if you're rejecting all new features that should be easier

[08:03:04.0000] <mkwst>
Naah, CSP3 is perfect. No maintenance necessary! Just don't ever change Fetch or HTML, plz.

[08:03:08.0000] <mkwst>
:)

[08:04:24.0000] <annevk>
sure

[09:43:07.0000] <domfarolino>
If by default, the credentials mode of fetch is `omit`, is there a situation where you'd ever need to explicitly specify `{credentials: 'omit'}`?

[10:42:28.0000] <annevk>
domfarolino: if you pass in a request object

[10:42:33.0000] <annevk>
domfarolino: it's a fallback default only used when the first argument is a string, iirc

[11:15:09.0000] <domfarolino>
annevk: it looks like a request object's default credentials property is "omit" (new Request().credentials yields "omit") which kinda does the explicit work for you.

[11:17:01.0000] <domfarolino>
annevk: I guess just passing {credentials: 'omit'} explicitly is added security or something

[11:20:18.0000] <annevk>
domfarolino: if you do new Request(existingRequest).credentials it isn't necessarily "omit" is what I'm saying

[11:21:42.0000] <domfarolino>
annevk: Ohh sorry, that makes sense thanks :)

[11:23:16.0000] <zcorpan>
Soooooo.... anyone think we should keep https://html-differences.whatwg.org/ alive and is interested enough to take over as editor? See https://github.com/whatwg/html-differences/issues/2

[11:25:08.0000] <zcorpan>
(A sort-of benefit from converting this document to bikeshed would be that HTML needs to more consistently export all elements and attributes etc.)

[11:31:20.0000] <zcorpan>
Also see https://github.com/whatwg/html-differences/pull/4

[11:34:45.0000] <jsbell>
annevk: if I can review any more test/spec PRs for you please ping (if github has a task list UI other than notifications it is well hidden)

[11:35:34.0000] <jgraham>
jsbell: Oh, annevk showed me this the other day

[11:35:38.0000] <annevk>
jsbell: there's https://github.com/pulls/review-requested but currently nothing outstanding I think

[11:35:39.0000] <jgraham>
It is well hidden!

[11:36:11.0000] <jsbell>
thx!

[11:36:33.0000] <annevk>
jsbell: someone noticed storage/interfaces.html might have to be renamed to https.html but I'm still awaiting answer on whether they want to land that Gecko side or have me do it

[11:37:04.0000] <annevk>
jsbell: and I'm also trying to figure out whether it would make sense to start using .any.js for more encoding/ tests or whether that would be somewhat bad money/resources wise

[11:38:13.0000] <jsbell>
I hadn't been aware of .any.js tests before; let me see if we even run them in blink...

[11:38:25.0000] <annevk>
(until yesterday we didn't have a single worker test it seemed)

[11:38:40.0000] <annevk>
jsbell: hmm I guess the idlharness test is also out-of-date

[11:48:28.0000] <jsbell>
Doesn't look like we run the .any.js tests in Blink yet, still digging though.

[11:48:48.0000] <gsnedders>
and .worker.js?

[11:49:07.0000] <gsnedders>
Both rely on wptserve, so I think they were previously not being run until that got enabled and stuck

[11:50:15.0000] <jsbell>
Do not seem to, but there's a chance I'm invoking wrong. wptserve is is enabled and stuck. Maybe I'm doing something wrong and/or we are missing some plumbing and/or we incorrectly filter them out...

[11:50:49.0000] <gsnedders>
Yeah, I know it's stuck. It's just maybe nobody has actually done it now it has stuck. :)

[11:56:40.0000] <jsbell>
Okay, known issue at least: https://crbug.com/653514 - I'll upvote/check status/etc

[14:55:09.0000] <KiChjang>
i need some help in understanding MessagePorts

[14:55:37.0000] <KiChjang>
https://html.spec.whatwg.org/multipage/comms.html#messageport

[14:56:03.0000] <KiChjang>
what happens to the tasks when the has_been_shipped flag is unset?

[14:56:21.0000] <KiChjang>
and similarly, what happens to the tasks when the port is disabled?

[14:56:30.0000] <KiChjang>
are they ever dropped?


2017-03-21
[22:45:11.0000] <KiChjang>
help on MessagePort?

[22:58:23.0000] <annevk>
KiChjang: what do you mean by disabled? close() is called?

[22:58:48.0000] <KiChjang>
annevk, its initial state when it was created

[22:58:53.0000] <KiChjang>
the spec says it's initially disabled

[22:59:18.0000] <annevk>
KiChjang: it doesn't say that about the port, it says that about its message queue

[22:59:25.0000] <KiChjang>
so in other words, if i queue a message task before start() is called, what happens?

[22:59:40.0000] <KiChjang>
does the port buffer the task?

[22:59:50.0000] <annevk>
KiChjang: the queue does

[23:00:52.0000] <KiChjang>
and when the queue itself is enabled, it would then fire the tasks off to their targets?

[23:01:14.0000] <annevk>
KiChjang: yeah, that's the intent, I have to say I've a hard time reading the spec as well

[23:01:31.0000] <KiChjang>
does the same happen for the has_been_shipped flag as well?

[23:01:39.0000] <annevk>
KiChjang: it could use some more refactoring maybe, though Domenic just improved some parts of this by redoing transfering and such

[23:03:19.0000] <KiChjang>
as in, the tasks also get buffered if the has_been_shipped flag is unset, and they would only be fired when it's set?

[23:03:48.0000] <KiChjang>
in which case, that would sound like enabling/disabling and the has_been_shipped flag does the exact same thing

[23:06:36.0000] <annevk>
KiChjang: I'm sorry, I don't think I understand the standard from a quick read

[23:07:02.0000] <annevk>
KiChjang: as I said, this might be worthy of some refactoring

[23:08:49.0000] <KiChjang>
annevk, ah ok, good thing i brought it up

[23:08:55.0000] <KiChjang>
shall i file an issue?

[23:09:04.0000] <annevk>
KiChjang: yeah

[23:09:09.0000] <annevk>
KiChjang: did you look for tests already?

[23:09:17.0000] <annevk>
KiChjang: might be handy to link any available tests too

[23:09:33.0000] <KiChjang>
annevk, yeah, that might clarify the behaviour a bit as well

[23:09:46.0000] <KiChjang>
i was purely looking to implement it

[01:46:21.0000] <zcorpan>
MikeSmith: https://github.com/validator/validator/pull/477

[02:04:34.0000] <tobie>
annevk: looking at https://github.com/whatwg/infra/issues/13

[02:04:58.0000] <tobie>
annevk: and just to make sure I understand the context clearly—

[02:05:46.0000] <tobie>
annevk: what you're looking for is an underlying data structure, not something that would end up in WebIDL, right?

[02:06:11.0000] <annevk>
tobie: just a convention I guess

[02:08:26.0000] <tobie>
annevk: so you could say something like: "a URL that has an origin example.com" ?

[02:09:21.0000] <tobie>
annevk: I'm basically trying to figure out whether this intersects with having a syntax for slots

[02:13:29.0000] <annevk>
tobie: just so that URL records and such are grounded somehow

[02:14:15.0000] <annevk>
tobie: slots are only for objects

[02:14:43.0000] <annevk>
tobie: a slot could hold such a tuple though I suppose

[02:20:04.0000] <Domenic>
An example is fetch

[02:20:12.0000] <Domenic>
A Response holds a response which is probably a tuple

[02:20:22.0000] <Domenic>
(sometimes known as a "concept-response" after it's #anchor)

[02:25:27.0000] <tobie>
looking

[02:29:41.0000] <tobie>
Mmm. In 1 <=> 1 relationships between concepts and WebIDL interfaces, I think I've been merging the two things and using slots as concept fields.

[02:30:10.0000] <tobie>
This might be a bad idea?

[02:31:09.0000] <tobie>
^ Domenic, annevk

[02:42:52.0000] <annevk>
tobie: no seems good for same instance

[02:43:18.0000] <annevk>
tobie: maybe not if not merged into one

[02:43:42.0000] <annevk>
tobie: out for a couple hours now

[02:57:49.0000] <tobie>
annevk: (when you're back—no hurry) how is this different for URL or response? Don't you have a 1:1 mapping?

[03:14:55.0000] <Domenic>
This seems kinda confused to me... an object has a slot which stores a concept. The concept then has lots of fields. This is useful when the concept is an independently useful entity like a response or URL.

[03:15:08.0000] <Domenic>
In other cases where there is no independently useful concept an object can have many slots

[03:19:01.0000] <tobie>
Domenic: wasn't suggesting absence of confusion. Quite the opposite actually. :)

[03:19:50.0000] <tobie>
Domenic: I guess what I was poking at was whether concepts would still exist if we had a good story for slots.

[03:20:02.0000] <tobie>
Domenic: sounds like the answer is yes.

[03:20:05.0000] <Domenic>
Yeah, they're what you store in the slots

[03:21:11.0000] <tobie>
Domenic: s/what/one of the things/ right?

[03:21:18.0000] <Domenic>
right :)

[03:21:52.0000] <tobie>
Domenic: not being pedantic, just making sure we're in agreement. :)

[03:22:33.0000] <tobie>
Domenic: so fields are slots for concepts, right?

[03:23:34.0000] <Domenic>
yeah, or for tuples at least. Although i'm not sure we've settled on the name "fields".

[03:24:08.0000] <Domenic>
Basically these are all different names for "properties" that are intentionally different so as to be less confusing. But maybe it is making it more confusing :P

[03:25:03.0000] <Domenic>
I guess the main reason "internal slot" and "property" are different is because they can live on the same thing, a JS/Web IDL object. (Although Web IDL calls them "attributes" instead of properties for... reasons.)

[03:25:45.0000] <tobie>
yes, the distinction in WebIDL makes sorta sense

[03:31:59.0000] <tobie>
What I don't understand from infra issues 13 and 21 is why do we want to give this abstract structure for concepts concrete qualities such as a fixed sized.

[03:37:51.0000] <Domenic>
I mean... would you rather them have an unfixed size?

[03:48:10.0000] <tobie>
 :D

[03:48:56.0000] <tobie>
No, I'm basically just wondering why we need an extra structure if maps are otherwise a good solution to map concepts.

[03:49:47.0000] <tobie>
(pun not intended)

[04:05:04.0000] <Domenic>
Well, it's the same reason that in languages we have classes/structs and not just hash maps

[04:05:50.0000] <Domenic>
Sure you can represent everything as a hash map. But it's important to give names to certain types, to say their shape is always a certain way, that they can be treated as a class, that their keys are always strings, that certain operations operate on them....

[04:21:13.0000] <jgraham>
Just tell tobie that hashmaps-everywhere are basically what Python does. I imagine he will find that convincing ;)

[04:21:53.0000] <jgraham>
(but ofc python does actually provide syntax over the hashmaps for the reasons that Domenic explains)

[04:22:12.0000] <tobie>
jgraham: the only thing I truly dislike about python is significant whitespace

[04:22:28.0000] <tobie>
feels gimmicky

[04:24:42.0000] <tobie>
Coming from JS (and before that, Ruby), hashmaps everywhere has a distinct homeland flavor

[04:26:50.0000] <tobie>
To come back to the issue at hand—I guess I'm sort of concerned that we're basically adding an lower-level type system to something that's already a lower-level type system to JS

[05:25:48.0000] <gsnedders>
do shared workers and service workers expose the exact same things as normal workers?

[05:27:33.0000] <Domenic>
gsnedders: no, you can use Exposed=SharedWorker or ServiceWorker or similar.

[05:27:48.0000] <Domenic>
And people do, especially for service

[05:28:50.0000] <gsnedders>
Domenic: thx

[05:31:22.0000] <gsnedders>
Domenic: but everything exposed on Worker is exposed in Shared/ServiceWorker? Where is that defined?

[05:31:44.0000] <MikeSmith>
zcorpan: yeah saw that validator PRーthanks. I just need to check out the branch and test it before merging. Will try to do that by tomorrow

[05:34:18.0000] <zcorpan>
MikeSmith: ok cool. i have tested it locally, fwiw

[05:35:38.0000] <nox>
I see that /websockets/interfaces/WebSocket/close/close-connecting.html doesn't pass in both Firefox and Safari, should I report that?

[06:17:39.0000] <annevk>
nox: yeah probably

[06:42:47.0000] <nox>
Ok.

[07:13:53.0000] <annevk>
tobie: sorry for short answers earlier, was trying to answer while walking around

[07:14:34.0000] <tobie>
annevk: no worries. :)

[07:14:41.0000] <annevk>
tobie: we basically invent new data structures for ease of notation or clarity on scope

[07:15:14.0000] <tobie>
annevk: not sure what you mean by clarity on scope, here.

[07:15:19.0000] <annevk>
tobie: both of those seem worthwhile and it also seems okay to have more types than JavaScript does at the moment, since JavaScript is still evolving as well

[07:15:54.0000] <annevk>
tobie: basically what can happen to the data structure, how it can be manipulated, which aspects can change, etc.

[07:16:08.0000] <tobie>
annevk: ok

[07:19:29.0000] <tobie>
annevk: Isn't what you need a struct?

[07:20:33.0000] <annevk>
tobie: maybe if that's like a tuple without order that'd be good, but that's also what JavaScript's Record type is I believe

[07:21:44.0000] <annevk>
tobie: maybe JavaScript's Record type is all we really need and we should just give up on tuples, although Records are oddly flexible sometimes in that they get extra fields

[07:22:04.0000] <tobie>
annevk: tuples don't have a key-value concept, though, do they?

[07:22:28.0000] <annevk>
tobie: they do in Infra's PR

[07:23:09.0000] <tobie>
so they're not *really* tuples, then

[08:12:06.0000] <annevk>
tobie: Python has named tuples

[08:12:24.0000] <tobie>
annevk: wat

[08:26:06.0000] <jgraham>
tobie: from collections import namedtuple

[08:26:18.0000] <jgraham>
It's a type that has ordered fields

[08:26:46.0000] <jgraham>
I mean it's a bit weird but not that weird because python allows destructuring tuples but not objects

[08:26:59.0000] <jgraham>
s/objects/other classes/ I guess

[08:27:39.0000] <jgraham>
Also it's the only immutable collection type

[08:28:14.0000] <jgraham>
So I guess you could say it is weird but only in the sense that Python was already weird here and we should all be using Standard ML or something

[08:36:41.0000] <annevk>
That wouldn't be normal either!

[09:07:13.0000] <nox>
Can someone help me walk through /websockets/cookies/007.html?

[09:28:59.0000] <gsnedders>
nox: probably zcorpan's test originally, fwiw

[09:31:58.0000] <Younder>
been watching Blink on 7

[09:33:20.0000] <Younder>
nice to see you are focusing on function instead of feature. No 1990 repeat. (worse is better)

[14:34:45.0000] <jyasskin>
The "current settings object" is the "relevant settings object" of the function that's currently executing, right?


2017-03-22
[00:59:39.0000] <Domenic>
jyasskin: functions don't have relevant settings objects

[00:59:56.0000] <Domenic>
but in some loose sense, that's basically true

[01:00:21.0000] <Domenic>
(functions have [[Realm]] slots, which could be said to be their relevant realm if you wanted)

[07:03:15.0000] <zcorpan>
<link rel="icon" href="c:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\fakepath\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\cupcakes.jpg" type="image/gif"/>

[07:05:46.0000] <MikeSmith>
👍

[07:11:52.0000] <annevk>
zcorpan: where was your utility to go from code point to longer name to put in a spec?

[07:12:22.0000] <zcorpan>
annevk: https://simon.html5.org/tools/js/unicodeize/

[07:13:43.0000] <zcorpan>
annevk: there's also http://software.hixie.ch/utilities/cgi/unicode-decoder/character-identifier

[07:20:06.0000] <annevk>
zcorpan: thanks, trying to figure out a consistent style to use in Infra (and then everywhere else)

[07:20:46.0000] <annevk>
zcorpan: I think I'm going with U+xxxx NAME IF IT CANNOT BE RENDERED or U+xxxx (RENDERED)

[07:21:16.0000] <annevk>
that way it's both brief and clear

[07:22:42.0000] <zcorpan>
annevk: and if it's several characters, just "foobar" ?

[07:23:04.0000] <annevk>
zcorpan: yeah, we'll keep that for strings and byte sequences

[07:23:16.0000] <annevk>
zcorpan: we already do that all over actually

[07:23:38.0000] <zcorpan>
SGTM

[07:27:52.0000] <annevk>
Are there any standardized names for byte values? Just like we have them for code points?

[10:38:14.0000] <smaug>
it would be nice to have one code indexing tool for all the open source browser engines

[10:39:00.0000] <smaug>
/me would suggest tool similar to searchfox.org

[10:39:21.0000] <smaug>
such tool would help with reverse engineering and such

[10:42:03.0000] <annevk>
smaug: not exactly reverse engineering if you just look at the code

[10:42:13.0000] <smaug>
true

[10:42:45.0000] <annevk>
Chromium has such a tool as well

[10:42:50.0000] <smaug>
oh, sure

[10:42:58.0000] <annevk>
https://cs.chromium.org/

[10:42:59.0000] <smaug>
but there are different tools

[10:43:10.0000] <smaug>
and certain tools a bit better than others ;)

[10:43:22.0000] <annevk>
and I guess WebKit has https://trac.webkit.org/

[10:43:27.0000] <annevk>
Yeah

[10:43:30.0000] <smaug>
trac is horrible

[10:43:45.0000] <annevk>
I'm not a fan either

[10:43:53.0000] <annevk>
Someone could create a mashup I suppose

[11:02:45.0000] <wanderview>
smaug: we could always host webkit and chromium in our search tool... i think freebsd used to do this for the linux kernel

[11:03:08.0000] <smaug>
need to ask billm if that was doable

[11:03:22.0000] <wanderview>
ah, they still do: http://fxr.watson.org/fxr/source/?v=HEAD

[11:03:23.0000] <smaug>
we used to have webkit or blink in mxr

[11:03:40.0000] <wanderview>
maybe not updated

[12:28:28.0000] <smaug>
jgraham: hmm, wpt doesn't have a way to dispatch trusted key events, right?

[12:29:21.0000] <jgraham>
smaug: No :(

[12:29:33.0000] <jgraham>
smaug: We want that to happen but so far no one did the work

[12:29:51.0000] <smaug>
yeah, would be nice

[12:29:57.0000] <smaug>
but ok, mochitest it is then

[15:06:16.0000] <jyasskin>
smaug: https://github.com/w3c/testharness.js/issues/142 tracks user gestures, which Chrome uses trusted key events to implement.

[15:06:53.0000] <gsnedders>
I still feel like testharnessreport.js is the wrong place to put this

[15:07:41.0000] <smaug>
jyasskin: how does that help with dispatching UA initiated events?

[15:08:50.0000] <jyasskin>
smaug: If you really need the key events, it doesn't. On the other hand, if we had the key events, we could use them to fix #142.

[15:09:11.0000] <smaug>
yeah, that way it would work

[15:09:27.0000] <smaug>
one often needs UA initiated events

[15:09:30.0000] <smaug>
in tests

[15:09:54.0000] <gsnedders>
jyasskin: why doesn't it help with dispatching UA initiated events?

[15:09:59.0000] <gsnedders>
am I missing something obvious here?

[15:10:56.0000] <jyasskin>
gsnedders: If we fix #142 literally, "Add a user-gesture helper function", then you can't get an arbitrary UA-initiated event given just a function to enable the user-gesture bit.

[15:11:12.0000] <gsnedders>
jyasskin: oh, rihght

[15:12:36.0000] <jyasskin>
I definitely wouldn't object if #142 were dup'ed against a bug in the right repository to add full trusted event dispatch.

[15:16:01.0000] <gsnedders>
jyasskin: I think NavidZ is working on that, hence #250/251

[15:16:58.0000] <jyasskin>
\o/


2017-03-23
[19:25:30.0000] <Domenic>
Does anyone have thoughts on mutable strings vs. immutable strings in specs? https://github.com/whatwg/infra/issues/91

[19:51:13.0000] <domfarolino>
Domenic: seems convenient for specs, and as far as prog langs go, I personally don't have an issue with the mutability of std::string in C++ :)

[20:32:29.0000] <MikeSmith>
Domenic: so if the spec language were changed what would it be changed to say? “Take the value of string foo and change it in this way to create string bar and then use that for baz”?

[20:53:07.0000] <MikeSmith>
Domenic: by the way it seems our buddy RichardMaher is back again in some GitHub issue-tracker discussions

[20:53:34.0000] <MikeSmith>
under the handle Solzhenitsyn

[20:54:27.0000] <MikeSmith>
https://github.com/w3c/push-api/issues/243#issuecomment-288586166

[20:54:38.0000] <MikeSmith>
and https://github.com/w3c/push-api/issues/243#issuecomment-288594110

[21:20:25.0000] <Domenic>
Oh, joy

[21:20:49.0000] <Domenic>
MikeSmith: yeah that would be the change. Reassigning variables to new strings, in general. Kind of annoying.

[23:36:27.0000] <MikeSmith>
Domenic: yeah sounds annoying enough that unless it’s really necessary we probably don’t want to voluntarily start doing that

[23:40:23.0000] <MikeSmith>
in other news, LinkedIn notification informs me that Andreas Bovens (formerly Opera) is now at Mozilla

[23:41:18.0000] <MikeSmith>
Lead, Product Management in Mozilla's Platform Product Management team

[02:16:16.0000] <tobie>
annevk/Domenic: looking at some of the latests infra issues, I see a tension building up between readability vs. precision.

[02:17:37.0000] <tobie>
annevk/Domenic: my gut reaction is that some of the things you're considering specifying in infra should be common sense,

[02:17:57.0000] <tobie>
but I'm not sure how colored by experience common sense actually is.

[02:18:41.0000] <tobie>
For example: is common sense of a JS dev the same as that of a C++ one?

[02:18:47.0000] <annevk>
tobie: I think most things we've filed something on has been the result of a question or problem seen somewhere

[02:19:15.0000] <annevk>
tobie: and as the topic of this channel indicates, there's no common sense on the web, so it's better to be explicit

[02:20:15.0000] <annevk>
tobie: I want to be extremely pedantic in Infra so the problem is solved for everyone, it seems to me that is how you build powerful abstractions that can last a long time

[02:22:39.0000] <mathiasbynens>
I feel like I’m missing some context here https://twitter.com/LeaVerou/status/844813111802585088

[02:24:08.0000] <tobie>
annevk: my other, related, concern is seeing typical comp lang issues such as variable scope creep up in spec prose.

[02:24:42.0000] <tobie>
annevk: such as the let/set question in conditional statements

[02:25:34.0000] <Domenic>
mathiasbynens: hmm. I remember two Lea bugs: one about how new URL() should use location.href as the base by default, which was rejected, and one about EventTarget.prototype.getEventListeners(), which got positive feedback and is waiting on implementer interest. I guess neither felt productive?

[02:25:35.0000] <tobie>
annevk: which sort of suddenly implies scopes which aren't clearly specified anywhere

[02:25:40.0000] <annevk>
mathiasbynens: one of https://github.com/issues?q=is%3Aissue+author%3ALeaVerou+user%3Awhatwg maybe?

[02:26:13.0000] <Domenic>
ah yes, asking for removing the data- requirement, also mostly rejected

[02:26:14.0000] <annevk>
mathiasbynens: the one on URL() didn't had a bit of a communication breakdown unfortunately, the others seemed okay, but maybe not

[02:26:25.0000] <annevk>
s/didn't//

[02:27:03.0000] <annevk>
tobie: right, that's why we need more precision, not common sense

[02:28:24.0000] <tobie>
annevk: yeah, I'm not arguing against this (gut reaction means precisely that).

[02:30:03.0000] <tobie>
annevk: perhaps I'm suggesting infra should preemptively address gut-reaction-based pushback?

[02:30:43.0000] <annevk>
tobie: heh, what would that mean?

[02:30:58.0000] <annevk>
"Trust us, you need this!"

[02:34:44.0000] <tobie>
annevk: well, I guess you could add as a goal to "help write clear and readable algorithmic prose by clarifying otherwise ambiguous concepts" or something like that

[02:35:24.0000] <annevk>
tobie: sounds reasonable, PRs appreciated

[02:36:22.0000] <tobie>
annevk: last related question which maybe I should open an issue for: how do you opt-in to that language without linking all the things?

[02:37:09.0000] <annevk>
tobie: there's some suggested boilerplate at the top

[02:37:23.0000] <annevk>
tobie: but we also strongly recommend linking the concepts just as you would xref other terms

[02:37:34.0000] <annevk>
tobie: shouldn't be much effort with Bikeshed

[02:38:24.0000] <tobie>
annevk: it's not so much effort vs spec will edn-up looking like christmas trees

[02:38:53.0000] <tobie>
e.g. let/set return, for loops, etc.

[02:39:11.0000] <tobie>
annevk: maybe that's something for the Bikeshed to solve, though

[02:42:23.0000] <Domenic>
I am personally not so sure about the linking

[02:42:31.0000] <Domenic>
I think it is fine to not link for things

[02:42:39.0000] <Domenic>
It's a gray area

[02:43:25.0000] <Domenic>
I think let/set/return/throw we have decided not to even given dfns because we don't want people linking to them.

[02:49:08.0000] <tobie>
Domenic: I think that has been brought up already in some of these issues, but how do you know whether you're using a "set" the way it's specified in infra vs. an unspecified, common-sense based approach?

[02:49:54.0000] <tobie>
Domenic: sepcifically in documents that are transitioning to relying on infra

[02:51:02.0000] <Domenic>
Well if you're transitioning then it seems like a bad idea to only use it some of the time

[02:53:52.0000] <annevk>
Everything that's transitioning will be somewhat ambiguous, but likely less so than before, since before it was undefined

[02:54:06.0000] <annevk>
Everything that's done transitioning or new should be good

[02:54:36.0000] <annevk>
Anyway, I'd be happy to require less linking, that's probably something we find out over time

[02:55:37.0000] <tobie>
annevk: I think I was pushing for *more* linking, but maybe a different way to present infra x-ref than the rest.

[02:56:07.0000] <tobie>
annevk: but you're right. This is something we'll find out over time.

[02:56:34.0000] <annevk>
I see, we've talked a little about that already in the context of private/public, might make sense to have something for Infra terms too

[02:56:48.0000] <annevk>
Though that'll also make it look like a Christmas tree

[02:57:06.0000] <tobie>
annevk: could be toggle-based.

[02:59:19.0000] <tobie>
annevk: just to clarify, I'm not pushing back against the whole idea of infra, btw, which I think you know I'm fully backing. Just attuned to how it makes me *feel* as an editor and trying to balance being explicit with being readable.

[03:27:45.0000] <mkwst>
speaking of telling editors what to do even if they don't like it, can we agree upon a standard way of describing algorithms?

[03:28:07.0000] <mkwst>
for instance, it would be lovely if we had a copy/pasteable way of describing inputs and outputs.

[03:28:16.0000] <mkwst>
every spec does it differently. or doesn't do it at all.

[03:28:53.0000] <mkwst>
(and it would get us closer to my secret dream of type checking if we also standardized the calling mechanism)

[03:36:43.0000] <annevk>
mkwst: yeah, file an issue?

[03:37:00.0000] <annevk>
mkwst: I'm planning on making Algorithms a top-level section and eventually address all their aspects

[03:37:31.0000] <annevk>
mkwst: doing it slowly though and adjusting standards that use Infra as we go

[03:44:50.0000] <mkwst>
Yup. Filed.

[08:12:31.0000] <mkwst>
annevk: How do you feel about https://w3c.github.io/webappsec-clear-site-data/#dom-api? Is it something you'd like to see upstreamed to Storage, or are you happy for it to live in this other doc until someone implements it?

[08:14:17.0000] <annevk>
mkwst: heh, was just filing issues

[08:14:35.0000] <mkwst>
Oh, great!

[08:17:22.0000] <AlexxNica>
Hey!

[08:18:31.0000] <AlexxNica>
Does anyone knows if for '<link rel="icon" href="favicon.png" sizes="16x16" type="image/png">' I'm obligated to keep the "icon" on quotes?

[08:18:52.0000] <AlexxNica>
Or can it be '<link rel=icon href="favicon.png" sizes="16x16" type="image/png">', skipping the quotes?

[08:24:09.0000] <annevk>
AlexxNica: you can skip the quotes for all those values

[08:29:24.0000] <AlexxNica>
annevk: Ok, nice! Do you know where I can find more info on this? Skipping quotes and whatnot

[08:33:30.0000] <annevk>
AlexxNica: https://html.spec.whatwg.org/multipage/syntax.html#attributes-2 is the authoritative source on this

[08:34:03.0000] <annevk>
AlexxNica: it might be a little hard to read though initially, pretty formal

[08:34:11.0000] <AlexxNica>
annevk: Great! Thank you very much!

[08:34:43.0000] <AlexxNica>
annevk: It's ok, the only problem I have is that I'm kind of impatient, so I may have skipped that part..

[08:35:50.0000] <AlexxNica>
annevk: I'm reading it all but because I don't have much time to do it I have the bad habit of skipping things..

[08:36:06.0000] <AlexxNica>
annevk: Not gonna do it again, again, thank you! 😁

[08:36:29.0000] <annevk>
AlexxNica: feel free to ask questions, happy to help

[08:36:45.0000] <annevk>
AlexxNica: "Unquoted attribute value syntax" is the exact bit

[08:37:06.0000] <AlexxNica>
annevk: Great to have people like you. 🤗

[08:47:43.0000] <annevk>
nox: "The same issue exists for the https to ws check." what test is that?

[08:48:00.0000] <nox>
annevk: We were discussing that in #servo let me paste the logs.

[08:49:21.0000] <nox>
annevk: But both WebKit nor Gecko throw anyway, so how can that change be intentional?

[08:50:09.0000] <annevk>
nox: because otherwise you have to duplicate all security checks and not forget each time you add a new security check

[08:50:26.0000] <annevk>
nox: the existing WebSocket setup is extremely fragile

[08:50:33.0000] <nox>
annevk: But isn't it a matter of web-compat by now?

[08:50:43.0000] <annevk>
nox: compat on exceptions?

[08:50:59.0000] <nox>
Well, nothing surprises me anymore.

[08:51:12.0000] <annevk>
It's worth a try to change this still I think

[08:55:34.0000] <nox>
annevk: Do you know in which step is the https to ws check done?

[08:56:12.0000] <annevk>
nox: step 5 of https://fetch.spec.whatwg.org/#main-fetch

[08:56:26.0000] <annevk>
nox: note that at that point the URL is already a HTTP URL

[08:56:35.0000] <nox>
Yeah.

[08:56:38.0000] <nox>
Thanks!

[08:56:40.0000] <annevk>
nox: due to https://fetch.spec.whatwg.org/#concept-websocket-establish

[09:32:45.0000] <ShaneHudson>
I'm currently doing some research into <textarea>. Probably quite a simple straightforward thing but if anyone has any interesting facts, bugs, or historical things then please do let me know!

[10:01:24.0000] <smaug>
annevk: reading https://html.spec.whatwg.org/multipage/dom.html#the-directionality . There is text like "The character is from a Text node..." My interpretation is that it includes also CDATA (since that inherits Text). Is that right?

[10:37:22.0000] <annevk>
smaug: yeah, but I want to make that clearer at some point

[10:37:41.0000] <smaug>
ok, thanks

[10:37:42.0000] <annevk>
ShaneHudson: there were quite a few issues recently around the API

[10:38:54.0000] <ShaneHudson>
annevk: Oh? Is there anything I can read about that, mailing list or irc log?

[10:40:09.0000] <annevk>
ShaneHudson: https://github.com/whatwg/html/issues?q=textarea has them all I think

[10:41:00.0000] <ShaneHudson>
Ah perfect, that will be really helpful cheers!

[12:34:05.0000] <zcorpan>
Edge's bug tracker's comment thing manage to mangle comments to no end... :-( https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11372968/

[12:35:19.0000] <annevk>
Yeah, best to keep it basic; newline-separated URLs


2017-03-24
[19:14:51.0000] <domfarolino>
Is the percentage of people heavily involved in standards AS WELL as implementing standards in a major browser fairly high, or not so much? I imagine most have some role in implementation, if only overseeing, but are many heavily involved in the development/implementation process as well?

[19:16:36.0000] <MikeSmith>
domfarolino: low

[19:16:56.0000] <MikeSmith>
in some browser project it’s higher, some very lower

[19:17:45.0000] <MikeSmith>
I guess the Chrome team and the Chromium project has way more than anybody

[19:18:41.0000] <MikeSmith>
Mozilla has fewer but the ones they have involved are highly prolific/productive, so it makes up for the difference in numbers some

[19:18:50.0000] <MikeSmith>
Opera was like that before too

[19:19:40.0000] <MikeSmith>
well and still now, though their implementation effort goes into Blink/Chromium

[19:21:04.0000] <MikeSmith>
Apple/WebKit probably has an even tinier implementation team, but is supporting some key people contributing to the design of the core specs, and testing

[19:22:51.0000] <MikeSmith>
anyway I guess it’s not about the numbers but instead about how effective individual people can be

[19:23:41.0000] <domfarolino>
I see. I guess I always kinda pictured the two groups as one , as it seems natural for implementers to know exactly would what is feasible and what is ridiculous

[19:23:43.0000] <MikeSmith>
a lot of the work spec-development work, I am not sure how much it would help to throw more people at it

[19:24:13.0000] <domfarolino>
standards is very interesting

[19:24:27.0000] <MikeSmith>
domfarolino: yeah as what is feasible and what is ridiculous, I guess communicating with implementors about that is one of the main things editors do

[19:24:34.0000] <domfarolino>
or *are*, if you take it as the collective plural

[19:24:42.0000] <MikeSmith>
yeah

[19:24:48.0000] <MikeSmith>
it is an odd world

[19:25:30.0000] <domfarolino>
Indeed, really cool though haha

[19:27:37.0000] <MikeSmith>
anyway, we say “editors” but we should say “collectors of information from implementors” because that is one the key tasks, and also “architects” because in that end that is what they do

[19:27:53.0000] <MikeSmith>
all from daily communication with implemetors

[19:28:14.0000] <MikeSmith>
the real bottleneck we have right now where we could use more people is for test review

[19:28:27.0000] <MikeSmith>
we need way, way more reviewers

[19:28:54.0000] <MikeSmith>
but it is basically a time-consuming, thankless, unrewarding task

[19:28:59.0000] <domfarolino>
Yeah, been learning a bit from the console standard

[19:29:07.0000] <MikeSmith>
ah yeah

[19:29:14.0000] <domfarolino>
Test reviewers as in people to review tests in the WPT repo?

[19:29:20.0000] <MikeSmith>
yes

[19:29:58.0000] <domfarolino>
Makes sense, I often see a lotta requests to review this and that

[19:30:22.0000] <domfarolino>
That repo is a beast too

[19:30:55.0000] <MikeSmith>
it has grown pretty enormously but is managed surprisingly well

[19:31:04.0000] <MikeSmith>
large credit due to jgraham personally

[19:31:24.0000] <MikeSmith>
but lots of other key contributions from a long tail of other people

[19:32:26.0000] <MikeSmith>
but the big problem there is way too much latency in reviews, test writers having to chase down people to beg for reviews, and then getting frustrated and risking to lose interest

[19:33:23.0000] <MikeSmith>
the WPT test-submission process is not something that in practice would lead most people to be enthusiastic about putting themselves through it again after they have done in the first time

[19:34:31.0000] <domfarolino>
Geez that's a shame. I imagine there's no real clear solution to that either, just slowly try to spark and hold more peoples' interest

[19:35:44.0000] <MikeSmith>
yeah I wish we could put some kind of better reward system around it

[19:36:52.0000] <MikeSmith>
give test reviewers some more recognition of some kind for their work

[19:37:04.0000] <MikeSmith>
test writers too

[19:37:17.0000] <MikeSmith>
good test writers at least

[19:37:51.0000] <MikeSmith>
we had this Test the Web Forward effort before but I think to some degree it gave the wrong incentives to test contributors

[19:38:05.0000] <MikeSmith>
and just created yet more work for test reviewers

[19:39:12.0000] <domfarolino>
yikes, backfire

[19:46:19.0000] <domfarolino>
MikeSmith: what did Test the Web Forward consist of that isn't seen now? Like, was there some sort of incentive behind it that has since been extinguished?

[19:47:46.0000] <MikeSmith>
we used to have face-to-face events

[19:48:01.0000] <MikeSmith>
hackathons, but for testing

[19:48:38.0000] <MikeSmith>
we would have people there who’d explain how to write tests, and then to do hands-on work with guiding people to work on writing their first tests

[19:48:56.0000] <MikeSmith>
the energy was great and it was all a lot of fun

[19:49:05.0000] <MikeSmith>
but we never got many good tests out of it

[19:49:31.0000] <MikeSmith>
lessons learned

[19:50:38.0000] <domfarolino>
ahh I see. it does sound fun, but it always amazes me (in a negative way), the quality of code produced at hackathons

[19:51:10.0000] <domfarolino>
for whatever reason it's just so conducive to terrible programming habits

[19:52:31.0000] <MikeSmith>
yeah?

[19:52:50.0000] <MikeSmith>
I’ve never been involved much in hackathons otherwise

[19:53:06.0000] <MikeSmith>
but anyway maybe I am being too critical about the experience

[19:53:28.0000] <MikeSmith>
the fact is I see we have 486 contributors for the repo

[19:53:33.0000] <MikeSmith>
https://github.com/w3c/web-platform-tests/

[19:53:45.0000] <MikeSmith>
which is pretty big by any measure

[20:13:09.0000] <domfarolino>
True

[20:14:57.0000] <domfarolino>
Yeah I help organize the hackathon at my university, that is I mainly do the web stuff but yeah it really pushes "Pick something up you've never touched before, learn it in the most superficial way, and build something quick with no tests"

[20:16:47.0000] <domfarolino>
"And make sure you don't further your education in the platform your developing on" lol

[20:29:26.0000] <MikeSmith>
heh :)

[00:28:21.0000] <Domenic>
A friend of mine is asking about resources for first-time spec writers. I was surprised to find I don't have many great answers. This might be especially complicated since his goal is more like API documentation than web platform specs; the idea is to give a contract to consumers of his software saying "this is how it works now, and we promise not to make it

[00:28:22.0000] <Domenic>
work differently in the future". But if anyone has any ideas

[00:40:02.0000] <KiChjang>
Domenic, would W3C have any resources on that?

[00:40:14.0000] <Domenic>
KiChjang: not that I know of

[00:41:31.0000] <KiChjang>
hmm, what do you call a promise that is non-binding?

[00:41:36.0000] <KiChjang>
a declaration?

[00:42:05.0000] <KiChjang>
/me just realized that this can totally be read in the context of JS or legalese

[01:00:36.0000] <tobie>
Domenic: I've had heated discussion about this topic in the past. Infra is a good first step even though it's not its main goal.

[01:39:48.0000] <annevk>
Domenic: Promises/A+ was kinda like that, no?

[01:43:41.0000] <zcorpan>
websocket.sub.js ;_;

[01:44:33.0000] <annevk>
zcorpan: you no longer like it?

[01:45:14.0000] <zcorpan>
annevk: i have never liked it (and I didn't write it)

[01:45:43.0000] <zcorpan>
annevk: this function doesn't return an object. it assigns to global `wsocket`

[01:48:47.0000] <annevk>
zcorpan: o_O

[01:48:48.0000] <zcorpan>
testing with port 80 and still get an error event. wonder why that is

[01:48:59.0000] <nox>
annevk: Re: wss: good to know.

[01:50:32.0000] <zcorpan>
oh it's testing wss:

[02:28:55.0000] <annevk>
zcorpan: if you could review https://github.com/w3c/web-platform-tests/pull/5217 that'd be nice

[02:47:52.0000] <nox>
annevk: What should the UA do if the server send back multiple Sec-WebSocket-Protocol headers?

[02:48:23.0000] <annevk>
nox: doesn't that just mean multiple protocols?

[02:48:36.0000] <annevk>
nox: I don't have the standard in memory

[02:48:38.0000] <nox>
annevk: "The |Sec-WebSocket-Protocol| header field MUST NOT appear more than once in an HTTP response."

[02:48:45.0000] <nox>
That's what the WS spec says.

[02:49:21.0000] <annevk>
nox: good times, arguably that means the handshake ought to fail, but tests / what do browsers do -> Fetch bug for clarification? (prefixed with WebSocket)

[02:49:41.0000] <annevk>
nox: or does it actually define what should happen when it occurs more than once?

[02:49:53.0000] <annevk>
nox: sometimes they do an attempt at error handling

[02:50:20.0000] <nox>
annevk: It doesn't AFAIK.

[02:50:32.0000] <nox>
annevk: Filed https://github.com/whatwg/fetch/issues/515

[04:40:06.0000] <zcorpan>
hmmmmmmm. wpt could pick a port that is blocked for ws:

[06:51:15.0000] <MikeSmith>
mkwst: for CSP in what case would I ever want to use the nonce attribute rather than a hash?

[06:51:58.0000] <MikeSmith>
is there some case where it would not be possible or practical to create/use a hash but it would be to use a nonce?

[07:03:19.0000] <gsnedders>
Why am I filing bugs on tr.rdf? :\

[07:04:29.0000] <jgraham>
You haven't been given enough work to do?

[07:04:37.0000] <jgraham>
rbyers: Pleases fix ;p

[07:05:25.0000] <jgraham>
(also my spelling)

[07:05:52.0000] <rbyers>
jgraham: Hah, you guys should tell me where the biggest opportunities for impact are ;-)

[07:06:56.0000] <gsnedders>
jgraham: tbf, I was trying to figure out what tobie wanted for the csswg-test merge and whether all shortnames matched what we have in csswg-test

[07:07:05.0000] <gsnedders>
jgraham: except, uh, hit bugs in tr.rdf

[07:08:37.0000] <gsnedders>
jgraham: I swear this is useful! tbf, it also affects Bikeshed and everything else that uses tr.rdf as the source for canonical shortnames

[07:10:35.0000] <MikeSmith>
plan is still to pull the trigger on the repo move Tuesday?

[07:11:22.0000] <tobie>
gsnedders: are you sure these are bugs in tr.rdf, not oddities of the CSSWG?

[07:11:46.0000] <gsnedders>
tobie: yes

[07:11:51.0000] <gsnedders>
MikeSmith: yes

[07:12:01.0000] <tobie>
gsnedders: oh wow.

[07:12:03.0000] <gsnedders>
MikeSmith: I need to email about that, thx for the reminder!

[07:12:07.0000] <tobie>
gsnedders: :D

[07:12:16.0000] <gsnedders>
tobie: notably, one TR document doesn't appear as a node in the graph at all!

[07:13:23.0000] <tobie>
"a node in the graph" <-- sounds like gsnedders drank the rdf koolaid. Who's close enough to intervene?

[07:15:35.0000] <gsnedders>
tobie: oh, I think it's 99.9% of the time totally gratuitous and not worth using, that doesn't mean I don't actually have a good understanding of it and much of the tooling around it

[09:44:05.0000] <MikeSmith>
annevk: Domenic the WebDriver spec references the dfn “code entry-point” from HTML. Should that ref be changed to “settings object”?

[10:23:07.0000] <smaug>
annevk: ping

[10:23:36.0000] <smaug>
or anyone, want to say if my interpretation of an algorithm is right?

[10:24:06.0000] <smaug>
https://html.spec.whatwg.org/multipage/dom.html#the-dir-attribute:the-dir-attribute-8

[10:24:23.0000] <smaug>
if bdi has dir="auto" and dir is then removed, nothing is supposed to change

[10:25:32.0000] <MikeSmith>
Domenic: annevk or maybe the algorithm at https://w3c.github.io/webdriver/webdriver-spec.html#dfn-execute-a-function-body needs to be updated to match what’s currently in HTML?

[10:26:25.0000] <MikeSmith>
but step 8 there, “Let script’s code entry-point be function” is the only one that has an HTML ref that no longer matches the spec

[13:00:05.0000] <jarek>
Hi

[13:00:05.0000] <botie>
what's up, jarek

[13:00:48.0000] <jarek>
Are there any recommendation on how to name custom attributes on custom elements?

[13:01:25.0000] <jarek>
some frameworks are using ":" prefix, for example <el-input-number :min="1" :max="10"></el-input-number>

[13:01:34.0000] <jarek>
others use data- prefix or no prefix at all

[13:14:31.0000] <jarek>
nvm, just found https://github.com/whatwg/html/issues/2271


2017-03-25
[19:03:55.0000] <Domenic>
MikeSmith: oof, that is a very old term that was changed a while ago... let's see...

[19:05:28.0000] <Domenic>
MikeSmith: that algorithm makes no sense to me, as it goes to a bunch of trouble to set up a _script_ variable that it then forgets to use.

[19:05:52.0000] <Domenic>
MikeSmith: I will open an issue proposing a better version...

[19:10:31.0000] <MikeSmith>
Domenic: thanksーwould much appreciate it

[19:10:59.0000] <MikeSmith>
am certain the webdriver editors will be happy to have it too

[19:20:37.0000] <Domenic>
https://github.com/w3c/webdriver/issues/869

[19:21:44.0000] <MikeSmith>
Domenic: cheers 🍸

[19:41:04.0000] <domfarolino>
Domenic: "clean up commit messages when merging in GitHub UI" as in eliminating the nasty asterisk commit summaries that appear in the description?

[19:46:33.0000] <domfarolino>
I'm assume that's what you meant, my bad!

[20:10:58.0000] <Domenic>
domfarolino: yeah exactly :)

[09:45:27.0000] <domfarolino>
has anyone had problems opening issues on the Edge issue tracker in the past little while? It just errors out for me :(

[09:57:40.0000] <annevk>
domfarolino: maybe use the Twitter reporting feature or contact one of them?

[12:30:49.0000] <MikeSmith>
https://bugs.webkit.org/show_bug.cgi?id=170075 doesn’t seem to be spec-conformant

[12:31:04.0000] <MikeSmith>
“Blobs can't be read in sandboxed iframes with allow-scripts

[12:31:11.0000] <MikeSmith>
"[blocked] The page at https://jsfiddle.net/bgh27rre/1/ was not allowed to display insecure content from blob:null/39cc8f5e-0ff2-4435-8e82-eedb3ce3091c."

[12:32:07.0000] <MikeSmith>
works fine in Firefox and Chrome but Safari gives the error avobe


2017-03-26
[06:50:00.0000] <MikeSmith>
XhmikosR: HTML checker v17.3.0 released and npm published

[07:14:44.0000] <XhmikosR>
MikeSmith: thanks, I'll publish a new version

[07:15:01.0000] <MikeSmith>
XhmikosR: super

[07:18:48.0000] <XhmikosR>
I went with a minor version bump

[07:20:48.0000] <MikeSmith>
that sounds appropriate, given no big feature changes

[07:22:05.0000] <MikeSmith>
and no breaking changes

[07:24:40.0000] <XhmikosR>
it should be a patch version then :P

[07:24:51.0000] <XhmikosR>
we really need to standarize this

[07:30:08.0000] <nox>
XhmikosR: semver?

[07:30:29.0000] <XhmikosR>
yup

[07:30:46.0000] <XhmikosR>
but MikeSmith still prefers the date approach :)

[07:31:25.0000] <XhmikosR>
every release I make it's like playing the lottery when it comes to choose a version number :p

[07:31:46.0000] <MikeSmith>
that sounds fun

[07:32:11.0000] <MikeSmith>
you should be thanking me for the excitement and surprise

[07:32:43.0000] <XhmikosR>
hehe

[07:33:57.0000] <XhmikosR>
I guess one alternative would be to bring grunt-html's version on par with vnu-jar; then I wouldn't have to worry about it and I could just use your version

[07:35:02.0000] <MikeSmith>
that sounds more disruptive for grunt-html users

[07:35:07.0000] <nox>
Dates don't help to detect breaking changes.

[07:35:48.0000] <MikeSmith>
well 17.3.0 is not a date

[07:36:49.0000] <XhmikosR>
it sort of is, YY.MM

[07:37:12.0000] <nox>
MikeSmith: March 17th, Year 0.

[07:37:25.0000] <XhmikosR>
anyway not a big deal, I just believe it would be better if this was standard

[08:31:33.0000] <XhmikosR>
MikeSmith: did something change recently regarding tables? I'm getting Element “tbody” not allowed as child of element “table” in this context. (Suppressing further errors from this subtree.) https://gist.github.com/XhmikosR/de3a984f163c1f4dbc6b8782e52ca05b

[08:32:20.0000] <XhmikosR>
must be https://github.com/validator/validator/issues/448

[09:34:45.0000] <MikeSmith>
XhmikosR: Yeah, that's it

[09:35:19.0000] <MikeSmith>
tfoot can no longer be used before tbody

[09:35:40.0000] <MikeSmith>
dunno why I didn't get that into the release notes


2017-03-27
[03:03:59.0000] <nox>
Where in the Fetch spec does it say to set the Origin header for WebSocket requests?

[03:19:35.0000] <MikeSmith>
nox: where it mentions ws: and wss: protocol?

[03:19:41.0000] <MikeSmith>
I thought it does there

[03:19:46.0000] <MikeSmith>
/me loosk

[03:19:51.0000] <nox>
MikeSmith: I don't see that.

[03:20:09.0000] <nox>
MikeSmith: All I see is "If the CORS flag is set or httpRequest’s method is neither `GET` nor `HEAD`, then append `Origin`/httpRequest’s origin, serialized and UTF-8 encoded, to httpRequest’s header list."

[03:20:21.0000] <nox>
Step 11 of http-network-or-cache-fetch,

[03:20:34.0000] <nox>
but AFAIK with a WebSocket request the CORS flag is unset.

[03:21:06.0000] <MikeSmith>
hmm then maybe in the HTML spec, where it calls the fetch algorithm for WebSocket requests

[03:21:24.0000] <nox>
MikeSmith: https://html.spec.whatwg.org/multipage/comms.html#dom-websocket Doesn't seem like it.

[03:22:06.0000] <MikeSmith>
right

[03:22:14.0000] <MikeSmith>
I see that just references https://fetch.spec.whatwg.org/#concept-websocket-establish

[03:25:03.0000] <nox>
MikeSmith: Seems like the step I mentioned should have an additional condition,

[03:25:15.0000] <nox>
MikeSmith: 'or request's mode is "websocket"'

[03:30:14.0000] <MikeSmith>
hmm yeah

[03:36:11.0000] <nox>
MikeSmith: When going through establish a ws connection,

[03:36:26.0000] <nox>
MikeSmith: can the response returned by basic fetch ever be a filtered response?

[03:36:47.0000] <nox>
In step 14 of https://fetch.spec.whatwg.org/#concept-main-fetch, that is.

[03:37:39.0000] <MikeSmith>
/me loosk

[03:41:08.0000] <MikeSmith>
nox: if the response tainting is the default “basic” it can, right?

[03:41:50.0000] <nox>
MikeSmith: Maybe?

[03:41:50.0000] <botie>
i heard Maybe was botie taking notes of who are going to TPAC

[03:41:50.0000] <MikeSmith>
request’s mode is "navigate" or "websocket"

[03:41:51.0000] <MikeSmith>
        Set request’s response tainting to "basic".

[03:42:06.0000] <annevk>
nox: if even same-origin WebSocket includes it I agree that we need a change there

[03:42:06.0000] <nox>
MikeSmith: Yeah but I'm not sure it matters in the particular case of websocket.

[03:42:28.0000] <MikeSmith>
Set response to the following filtered response with response as its internal response, depending on request’s response tainting:

[03:42:29.0000] <annevk>
nox: I guess the WebSocket handshake request uses GET?

[03:42:31.0000] <MikeSmith>
"basic"

[03:42:34.0000] <MikeSmith>
    basic filtered response

[03:42:39.0000] <nox>
annevk: It does.

[03:42:53.0000] <MikeSmith>
yeah it does

[03:43:10.0000] <annevk>
nox: I think you're right then that we need to include mode is websocket

[03:43:11.0000] <MikeSmith>
it does use GET because it defaults to that, right?

[03:44:23.0000] <nox>
MikeSmith: Oh I see the step you pasted,

[03:44:44.0000] <nox>
MikeSmith: but the previous step to the one which you pasted is "If response is not a network error and response is not a filtered response, then run these substeps:",

[03:45:07.0000] <nox>
MikeSmith: can HTTP fetch itself return a filtered response for ws?

[03:45:07.0000] <MikeSmith>
aha

[03:45:34.0000] <MikeSmith>
nox: it cannot there as far as I can see

[03:48:27.0000] <nox>
MikeSmith: Thanks!

[03:50:02.0000] <MikeSmith>
cheers

[03:50:48.0000] <MikeSmith>
the more I read the Fetch spec the more I think there’s no way to understand it without implementing it

[03:50:58.0000] <MikeSmith>
which I’m not doing

[03:51:04.0000] <MikeSmith>
but which I guess you are

[03:52:23.0000] <nox>
MikeSmith: It's worse than that.

[03:52:39.0000] <nox>
MikeSmith: Our Fetch impl currently doesn't allow us to use these algos from the websocket case,

[03:52:58.0000] <nox>
MikeSmith: and the three existing Rust impls of websocket don't play well with that spec in general,

[03:53:16.0000] <nox>
so I'm reimplementing these algos special-cased for ws, and doing ws handshake myself from Servo's code directly.

[03:53:46.0000] <nox>
The unfiltered internal response does not matter in the ws case, right?

[03:54:36.0000] <nox>
Actually, does filtering these responses matter at all?

[03:54:46.0000] <nox>
The response is never exposed to the Web for websockets, right?

[03:55:06.0000] <MikeSmith>
I guess not unless some other spec says it is?

[03:55:29.0000] <nox>
MikeSmith: You devil.

[03:55:30.0000] <MikeSmith>
which if so should only be the HTML spec I’d think

[03:55:33.0000] <MikeSmith>
heh

[03:55:38.0000] <MikeSmith>
*snort*

[03:57:01.0000] <MikeSmith>
the Fetch spec should be used on people as a test of how must perseverance they have

[03:57:20.0000] <nox>
Heh.

[04:36:28.0000] <nox>
MikeSmith, annevk: https://github.com/whatwg/fetch/pull/518

[04:48:57.0000] <annevk>
reviewed

[04:49:17.0000] <nox>
annevk: Amended.

[04:49:59.0000] <annevk>
nox: do you know if we have tests?

[04:50:27.0000] <nox>
annevk: Absolutely no idea, but the Origin header seems core to WS to me, so it wouldn't surprise me if we do.

[06:19:27.0000] <nox>
annevk, MikeSmith: Shouldn't step 22.5.2. be avoided for websocket stuff?

[06:19:42.0000] <nox>
annevk, MikeSmith: Why should even the response be cached at all if the cache mode is no-store?

[06:20:06.0000] <nox>
Ah nevermind, that's covered by the mentioned RFC...

[06:20:27.0000] <annevk>
nox: might be a recent regression, mnot revamped the cache bits

[06:47:24.0000] <smaug>
/me wants "right after rAF" callback

[06:49:12.0000] <annevk>
smaug: I think you filed a bug for that at some point, it hasn't gotten fixed thus far

[06:49:21.0000] <smaug>
I did

[06:50:14.0000] <smaug>
it just occurs every now and then when I write some benchmarking like code that I end up doing rAF(function(setTimeout(...)))

[06:50:34.0000] <smaug>
hmm, perhaps I could use requestIdleCallback

[07:17:52.0000] <nox>
annevk: What about the last bullet of step 5 of https://fetch.spec.whatwg.org/#concept-http-network-fetch?

[07:18:14.0000] <nox>
annevk: Is the server allowed to return some non-101 1xx response, and then the 101 one, for WebSocket?

[07:21:30.0000] <annevk>
nox: per the new definition yes, but this wasn't tested

[07:21:49.0000] <annevk>
nox: not sure what's desired

[07:22:15.0000] <annevk>
nox: making the handshake behave as much as the rest of the networking stack as possible probably is, so ignoring seems better?

[07:42:10.0000] <annevk>
zcorpan: per grep  websockets/Create-Secure-blocked-port.htm is the only resource that makes use of websocket.sub.js

[07:42:30.0000] <zcorpan>
annevk: huh

[07:42:35.0000] <annevk>
zcorpan: I think I'll push another fixup that basically inlines the creation of that function

[07:42:51.0000] <annevk>
zcorpan: sorry, for CreateWebSocketWithBlockedPort

[07:43:03.0000] <annevk>
zcorpan: per "grep CreateWebSocketWithBlockedPort -r *"

[07:43:12.0000] <zcorpan>
annevk: ah, yes indeed

[07:44:06.0000] <zcorpan>
need .sub.html on test then to get the port that should work

[07:48:19.0000] <annevk>
ah right, skipped inlining for now and just made it return

[07:48:28.0000] <annevk>
websocket.sub.js already returns sometimes

[07:49:52.0000] <annevk>
mkwst: ping for https://github.com/whatwg/html/issues/2460

[07:49:53.0000] <botie>
will do

[07:56:25.0000] <annevk>
domfarolino: filed an Edge issue successfully just now btw

[07:59:03.0000] <domfarolino>
annevk: thanks for the heads up! Forgot to reply the other day, ended up using the twitter reporting which worked great

[08:03:56.0000] <mkwst>
annevk: Thanks! I've thrown it at folks smarter than me.

[08:08:05.0000] <nox>
annevk: In step 5 of https://fetch.spec.whatwg.org/#concept-http-network-fetch,

[08:08:15.0000] <nox>
it says 'If request’s header list contains `Transfer-Encoding`/`chunked` and response is transferred via HTTP/1.0 or older, then return a network error.',

[08:08:26.0000] <nox>
and then 'Transmit body for request',

[08:08:38.0000] <nox>
how can we know the response is transferred via HTTP/1.0 before even sending the body?

[08:11:06.0000] <annevk>
nox: it's possible in theory to get an early response, but I guess that should be part of the caveats somehow

[08:12:02.0000] <annevk>
nox: all of step 5 is sort of continuous in a way :/

[08:12:17.0000] <annevk>
nox: main problem is that standards are not nicely layered

[08:12:34.0000] <nox>
annevk: Oh really! ;)

[08:48:24.0000] <annevk>
There really should be some kind of way to rebase where it adds a commit for rebase conflicts that makes the rebasing work and that can then be reviewed

[08:48:59.0000] <annevk>
Just rebasing and force pushing and no longer being sure about your entire review is really bad

[15:21:44.0000] <tobie>
Domenic: looking at https://github.com/heycam/webidl/pull/286 today hoping to be able to merge it, I'm left wondering whether the right decision wouldn't be to have a separate syntax for type modifiers vs. extended attributes.

[15:23:28.0000] <tobie>
Domenic: [clamp] on a dictionary member clearly addresses the type, while the hinted at [SecureContext] on the same member, clearly addresses the member.

[15:33:26.0000] <tobie>
Domenic: mmm. letting it sink in, it seems these distinctions will be completely opaque unless you're attempting to specify extended attributes.


2017-03-28
[17:50:55.0000] <Domenic>
annevk: I think that's called a merge commit

[17:51:13.0000] <Domenic>
I don't use it often so I don't remember the commands but it seems pretty legit

[17:51:48.0000] <Domenic>
tobie: yeah, that is kind of the plan; nobody should really care, so it's probably not worth making the distinction.

[17:52:12.0000] <Domenic>
I would really like bz to review but every time I ping him he's busy, so maybe we should go ahead and he can review post-facto if he finds anything... It would be good to un-block the SharedArrayBuffer work.

[18:43:26.0000] <Domenic>
tantek: MikeSmith: do you have thoughts on https://github.com/whatwg/html/issues/2351 ?

[18:44:18.0000] <tantek>
well that's always a good sign, to be paired with MikeSmith

[18:44:20.0000] <tantek>
/me looks

[18:45:12.0000] <tantek>
really we have no rel-canonical "spec" per se? I find that a bit, surprising. Let me look a bit.

[18:45:49.0000] <tantek>
"This article is a stub" 😂😂😂 http://microformats.org/wiki/rel-canonical

[18:46:01.0000] <tantek>
well we have a *stub* of a spec

[18:46:14.0000] <tantek>
seems like people though it was "obvious" enough to not need a spec?

[18:46:23.0000] <tantek>
(which of course isn't the best reasoning obv)

[18:46:55.0000] <tantek>
adding to issue

[18:49:28.0000] <Domenic>
\o/

[18:49:43.0000] <tantek>
Thanks for the heads-up Domenic

[18:51:02.0000] <tantek>
 hope the comments on the issue are helpful

[19:11:52.0000] <MikeSmith>
Domenic: do UAs do anything with rel=canonical?

[19:12:11.0000] <Domenic>
MikeSmith: not browser UAs I think, but lots of other UAs

[19:12:40.0000] <MikeSmith>
OK

[19:13:17.0000] <MikeSmith>
well if we do this systematically maybe we could consider setting a usage threshold for what rel values we include in the spec

[19:13:29.0000] <MikeSmith>
I could add a use counter to the checker

[19:13:40.0000] <MikeSmith>
and Simon could do a query

[19:13:51.0000] <tantek>
maybe we could start with determining the usage #s for the *existing* values in the spec?

[19:13:57.0000] <MikeSmith>
yeah that too

[19:14:00.0000] <MikeSmith>
good point

[19:14:06.0000] <tantek>
to see if usage-based-inclusion makes sense at all?

[19:14:17.0000] <tantek>
(not saying it doesn't just saying we can check the "control" as it were ;) )

[19:14:43.0000] <tantek>
meanwhile I pinged kevinmarks to braindump his thoughts/knowledge of rel=canonical into the wiki page in spec-ese

[19:14:50.0000] <tantek>
(in the gh issue of course0

[19:14:51.0000] <tantek>
)

[19:15:13.0000] <tantek>
might as well start writing things up formally, whereever they end up

[19:15:43.0000] <MikeSmith>
I guess I would expect the ones we already have in the spec to have relatively high usage, but that some values we don’t yet have in the spec, like rel=canonical, might have even higher usage than some already in the spec

[19:16:09.0000] <tantek>
yeah, plus I'd expect some in the spec to have low usage because they may have been more, um, aspirational as it were ;)

[19:17:09.0000] <tantek>
rel values in general have been falling out of vogue too - e.g. in #microformats and #indieweb we've largely switched over to using properties of objects, because rel values are nearly only useful for page-level-scope, and many things (like blog posts) can occur multiple times on a page

[19:17:41.0000] <tantek>
might as well document the ones that are in use though (published and consumed)

[19:17:54.0000] <tantek>
also would be good to get an updated survey since the 2004/2005 one that Hixie did

[19:18:11.0000] <tantek>
we're likely to have different results today than 12ish years ago

[20:11:31.0000] <MikeSmith>
Domenic: OK I just added a rel=canonical use counter to the W3C HTML checker

[20:11:46.0000] <MikeSmith>
running results are at https://validator.w3.org/nu/stats.html

[20:12:37.0000] <MikeSmith>
currently 170 documents out of 522 have rel=canonical

[20:12:50.0000] <MikeSmith>
33%

[20:13:09.0000] <MikeSmith>
which seems high but am pretty sure my code is right

[20:13:59.0000] <MikeSmith>
https://github.com/validator/validator/commit/c8013ba526d639aab742020c7b71584f27a2bad2?diff=unified#diff-5c9743fbd69f36c7a9eb6a7a91bce31fR441

[20:14:15.0000] <MikeSmith>
the use counter only logs it once per document

[20:31:05.0000] <MikeSmith>
still, 33% seems very high

[20:36:08.0000] <MikeSmith>
https://cdn.rawgit.com/operasoftware/devopera-static-backup/869f534a/http/dev.opera.com/articles/view/mama-head-structure/index.html#link

[20:36:20.0000] <MikeSmith>
https://cdn.rawgit.com/operasoftware/devopera-static-backup/869f534a/http/devfiles.myopera.com/articles/575/linkrellist-url.htm

[21:08:54.0000] <annevk>
Domenic: a merge commit often seems to involve all of master and is therefore not super clear, but I could be missing something

[21:10:14.0000] <Domenic>
annevk: I've seen at least some cases where it creates a single commit like "merged remote tracking branch origin/master" which basically includes all changes to master since the base point. If the merge is not trivial then that commit also includes changes made to reconcile. Then when you diff the whole result (pr commits + merge commit) against the current

[21:10:14.0000] <Domenic>
master, you see PR changes + changes made during the merge commit to reconcile with latest master

[22:56:22.0000] <annevk>
I guess I have to see one again to remember why that isn't quite what I want

[22:57:19.0000] <annevk>
Making rebasing work is usually a fairly trivial though easy to get wrong operation, but a merge commit doesn't really show it clearly as such

[22:59:19.0000] <annevk>
Domenic: you want to add null/false/true?

[23:00:00.0000] <Domenic>
annevk: not immediately; while in Tokyo focusing on streams + modules. But I can definitely take it in the next few weeks if you're not in a rush.

[23:00:24.0000] <Domenic>
What does servo use for xml?

[23:00:35.0000] <annevk>
Domenic: html5ever I think

[23:00:41.0000] <Domenic>
So no XML?

[23:01:18.0000] <annevk>
Domenic: "XML5", it's part of the same package

[23:01:28.0000] <annevk>
Domenic: reuses a bunch of logic

[23:02:57.0000] <Domenic>
Ah OK

[23:02:59.0000] <annevk>
Unfortunately WebKit doesn't seem interested in refactoring that code

[23:03:13.0000] <annevk>
I think Gecko would eventually replace its XML parser with something better

[23:03:24.0000] <Domenic>
Well we're not fans of libxml over in Blink either, /cc dominicc

[23:03:28.0000] <annevk>
If everyone did we'd have our HTML parser escape

[23:03:31.0000] <Domenic>
Constant security bugs

[23:03:40.0000] <Domenic>
So thinking about replacements

[23:04:02.0000] <annevk>
XML would end up winning after all, with a slight "HTML5" touch to remove its worst aspects

[23:04:03.0000] <Domenic>
cc nox

[23:04:45.0000] <Domenic>
It seems like there are several possibilities though https://crates.io/search?q=xml

[23:07:11.0000] <Domenic>
Hmm I'm not sure things like omitting <!DOCTYPE> entity substitution is web compatible

[23:07:41.0000] <annevk>
Domenic: XML5 handles that

[23:07:50.0000] <annevk>
At least the version I wrote originally

[23:07:52.0000] <Domenic>
Interesting, xml-rs does not

[23:08:09.0000] <annevk>
Oh, xml-rs seems like something else

[23:08:30.0000] <annevk>
I don't think Servo uses that

[23:09:43.0000] <Domenic>
Yeah, it's the most popular when searching for "xml"

[00:08:35.0000] <nox>
Domenic: We use xml5ever.

[00:09:05.0000] <nox>
Domenic: XML and Rust don't quite fit together for now.

[00:35:48.0000] <annevk>
Domenic: adding noncharacter to Infra seems fine, but note that it's only used for conformance requirements

[00:35:55.0000] <Domenic>
hmm

[00:36:03.0000] <Domenic>
seems fine I guess

[01:02:17.0000] <annevk>
Domenic: what platform feature is driving writable streams?

[01:02:25.0000] <Domenic>
annevk: mostly transform streams :)

[01:02:47.0000] <annevk>
Domenic: and those are driven by text encoding/decoding?

[01:02:49.0000] <tobie>
Domenic: catching up on extended attributes for types, my only concern is the lack of clarity as to whether the annotated types are types of their own or not.

[01:03:09.0000] <Domenic>
annevk: text is the easy case, but we have lots more lined up; gzip and media off the top of my head

[01:03:23.0000] <Domenic>
tobie: hmm I think I made it pretty clear they are?

[01:03:30.0000] <annevk>
Domenic: ta

[01:03:40.0000] <Domenic>
annevk: also https://streams.spec.whatwg.org/#example-pipe-as-chunks-receiver

[01:03:53.0000] <tobie>
Domenic: OK, I thought so, but then doesn't that affect the overload resolution algorithm?

[01:04:09.0000] <Domenic>
tobie: hmmm I guess I didn't consider that fully; I should check.

[01:04:42.0000] <tobie>
Domenic: I think the right thing to do would be to have something similar to inner types for nullables

[01:04:50.0000] <Domenic>
tobie: agreed

[01:05:14.0000] <Domenic>
nullable is the right model here

[01:05:18.0000] <tobie>
Domenic: and then just grab those in the overload resolution algorithm

[01:05:49.0000] <tobie>
Domenic: well, except the relation is a one to many here, not a one to one.

[01:06:15.0000] <tobie>
Domenic: plus you can have an annotated type which is also nullable, no?

[01:07:02.0000] <Domenic>
yeah, there's a general "inner type" concept hiding I guess

[01:07:27.0000] <Domenic>
? suffix is just shorthand for [Nullable] prefix in this framework, at least conceptually. Probably not worth actually doing that though.

[01:07:40.0000] <tobie>
Domenic: oh!

[01:09:47.0000] <tobie>
Domenic: that seems like the right model.

[01:10:31.0000] <tobie>
Domenic: it also looks like quite a lot of work to rework. :-/

[01:11:23.0000] <tobie>
Domenic: I think you'll need to figure out the relationship with inner type either way, though.

[01:11:51.0000] <tobie>
Domenic: Alright, I'll finish my review and send it over.

[01:12:49.0000] <tobie>
Domenic: I'm pretty confident given the various threads on this topic that we can land this once we fix this last thing

[01:13:18.0000] <tobie>
Domenic: and bz can file against the spec if he bumps on issues down the road

[01:14:48.0000] <Domenic>
tobie: sounds great, thanks so much for looking into it

[01:15:41.0000] <tobie>
Domenic: I should have done that a ling time ago. Apologies for not looking into it before. It looked sort of daunting tbh.

[01:16:18.0000] <MikeSmith>
zcorpan: wonder if you could please run a query for rel=canonical usage

[02:02:23.0000] <annevk>
If we get [Nullable] we might be able to start using [Undefinedable] too if there's still appetite for that

[02:02:53.0000] <annevk>
Although I guess we could already if we just had an undefined value

[02:03:02.0000] <annevk>
Domenic: why is ? not short for " or null"?

[02:03:34.0000] <Domenic>
annevk: it is but "or null" can be modeled in terms of [Nullable] applied to the type i.e. it creates a new type

[02:09:53.0000] <tobie>
Domenic: alright, pushed the review.

[02:11:05.0000] <Domenic>
Good review :). It's getting late in Tokyo so I'll work on it tomorrow.

[02:15:38.0000] <tobie>
Domenic: oh, that's where you are. Enjoy!

[03:20:53.0000] <zcorpan>
MikeSmith: yeah i'll do that now

[03:21:25.0000] <zcorpan>
MikeSmith: only on <link>?

[03:28:33.0000] <zcorpan>
MikeSmith: 278679 matches

[03:43:17.0000] <jochen__>
what spec defines how e.g. <xsl:import> loads resources in a browser?

[03:45:38.0000] <gsnedders>
jochen__: none does

[04:23:25.0000] <jochen__>
perfect :/

[04:25:44.0000] <wanderview>
annevk: is there any discussion towards this "html modules" proposal here: https://github.com/dglazkov/webcomponents/blob/html-modules/proposals/HTML-Imports-and-ES-Modules.md

[04:26:02.0000] <wanderview>
basically building a system similar to html imports on es module loader infrastructure

[04:26:45.0000] <annevk>
wanderview: there was a discussion at TPAC, most folks expressed a desire for ES modules to get some adoption first before looking into it further

[04:27:06.0000] <wanderview>
annevk: ok, thanks

[04:27:21.0000] <annevk>
wanderview: note that it's unclear to me at this point that the Loader idea is going to make it, it might be that service workers is sufficient

[04:27:51.0000] <wanderview>
annevk: service workers is a replacement for html imports use case?

[04:27:51.0000] <annevk>
(assuming you were referring to that, and not JS module loading in general)

[04:28:12.0000] <annevk>
wanderview: just for the hooks defined by Loader

[04:28:32.0000] <annevk>
https://whatwg.github.io/loader/

[04:28:58.0000] <wanderview>
annevk: the idea being that a service worker could synthesize the document with the stuff already in it?

[04:29:02.0000] <Domenic>
wanderview: annevk: kochi is interested in working on HTML modules

[04:29:33.0000] <annevk>
wanderview: I didn't mean to suggest service workers as a replacement for HTML modules, just for the hooks defined by Loader

[04:37:24.0000] <MikeSmith>
zcorpan: thanks

[04:37:30.0000] <MikeSmith>
zcorpan: 278679 matches out of what total?

[04:38:54.0000] <zcorpan>
MikeSmith: 17,103,665 resoures from 481,455 sites

[04:40:15.0000] <zcorpan>
MikeSmith: i guess you need to filter the results by unique `page` (or group by page) if you want to know the number of sites

[04:46:12.0000] <MikeSmith>
ok

[04:58:24.0000] <felixjet>
is there any <link> or <meta> tags that accepts content?

[04:58:31.0000] <felixjet>
like: <link>content</link>

[04:59:29.0000] <Domenic>
<a>

[05:08:03.0000] <Domenic>
I wonder where n1tm, our Gecko dialog implementer, went :(

[13:32:31.0000] <zcorpan>
gsnedders: \o/

[13:48:24.0000] <zcorpan>
Domenic: maybe we should merge the logical props dialog change and tests without their sanity check

[13:56:07.0000] <TabAtkins>
tobie: Why are you and Yehuda suddenly so interested in that BlinkOn thread of mine?

[13:58:32.0000] <tobie>
dunno. just saw it now.

[13:58:50.0000] <tobie>
TabAtkins: thought it was current

[13:59:23.0000] <TabAtkins>
Ah, kk.


2017-03-29
[17:25:06.0000] <Domenic>
zcorpan: that'd work for me

[21:57:20.0000] <kochi>
wanderview: are you interested in designing a successor of HTML Imports?

[21:58:06.0000] <wanderview>
kochi: uh... I'm really just interested in trying to understand the benefits of html imports compared to es modules... I know slightlyoff doesn't think es modules is a replacement

[21:58:22.0000] <wanderview>
kochi: which led me to reading the html imports spec and then wondering how it works with service workers, etc

[21:59:39.0000] <kochi>
wanderview: I guess technically ES modules can polyfill what HTML Imports can do, by embedding HTML and style in JS string :)

[22:00:27.0000] <wanderview>
kochi: right, but from what I have read it seems html imports supports progressive loading while es modules will require all dependencies to be loaded in strict sequence before evaluation

[22:00:56.0000] <kochi>
Using native HTML parser can have benefit over converting string to HTML via .innerHTML or DOMParser API, though.

[22:01:05.0000] <wanderview>
right

[22:01:50.0000] <wanderview>
kochi: it would be nice to see data showing perf benefits of html imports compared to a js polyfill...

[22:02:05.0000] <kochi>
and yeah, ES modules starts evaluation of the whole script once all the dependency graph is resolved and loaded, while in HTML Imports script inside an HTML Import can be run while loading other dependency branch.

[22:03:30.0000] <wanderview>
kochi: I guess I should be clear these questions are just coming from personal interest and don't really reflect any change in position from mozilla

[22:04:25.0000] <kochi>
well, I also would like to have concrete data :) Alex Russel might have some, will ask him.  He mentioned such benefit in his talks.

[22:05:26.0000] <kochi>
wanderview: ok, I won't take it as mozilla's action, but I'd more than welcome your personal interests :)

[22:05:40.0000] <kochi>
happy to answer any questions

[22:05:41.0000] <wanderview>
kochi: I asked about data again on twitter last night :-) https://twitter.com/wanderview/status/846687836615028741

[22:06:05.0000] <kochi>
good :)

[22:06:58.0000] <wanderview>
kochi: I'm going to see him at the SW spec meeting next week, so I'll ask him there as well

[22:07:13.0000] <kochi>
oh, are you here in Tokyo?

[22:07:25.0000] <wanderview>
I'm in Taipei at the moment... I arrive in Tokyo Saturday

[22:07:55.0000] <kochi>
okay, that's why your response is so quick :)

[22:08:04.0000] <wanderview>
yes, I'm awake! :-)

[22:10:51.0000] <kochi>
Practically html loading network round-trip time >>>> time required to parse HTML, I guess, so the benefit of parallelizing HTML import and HTML parsing is marginal, but in the age of H2 when the server side is more optimized to fill the loading pipeline, that optimization can be useful.

[22:13:00.0000] <wanderview>
so the es modules approach would parallelize all the network loads, but would delay the evaluation until all loads have completed?

[22:16:01.0000] <kochi>
yeah, es modules resolve all imports/exports before evaluation.

[22:16:31.0000] <wanderview>
but does the network loading happen in parallel?  I guess I wasn't clear on that point

[22:18:54.0000] <wanderview>
I guess I should read up on how es modules does that

[22:18:59.0000] <kochi>
one of the merits of es module is that import dependency can be analyzed statically by parsing module script, no need to evaluate the code.

[22:19:33.0000] <wanderview>
ah

[22:20:25.0000] <kochi>
and that's why dynamic import() is not there in the first implementation of ES modules.

[22:21:55.0000] <wanderview>
I guess the question then is how much benefit is there to being able to run html/style parsers while other dependents are loading from network

[22:22:06.0000] <kochi>
So if an ES module A imports B, C, D, then loading B,C, D can be in parallel.

[22:23:15.0000] <wanderview>
and modules approach requires double parsing html/style resources... first as js and then as final html/css after dynamically inserted

[22:23:29.0000] <wanderview>
and html/css strings must be kept in memory due to js .source requirements

[22:23:38.0000] <kochi>
true.

[22:23:48.0000] <Domenic>
(^ all this seems accurate)

[22:23:56.0000] <wanderview>
Alex Russel mentioned some issue about css-in-js causing cache problems... thats the one I don't understand

[22:25:02.0000] <wanderview>
I guess maybe separate html/css resources can be cached separately giving a finer grained cache... but not sure if that is what he meant

[22:25:02.0000] <kochi>
hmm, I want to know what he exactly said, but one reason I can think of is,

[22:26:21.0000] <wanderview>
kochi: I saw it here: https://twitter.com/slightlylate/status/845435543647248384

[22:26:23.0000] <kochi>
when Shadow DOM is used for a component, each shadow has its own style. Many of the same components are used in one document, there are multiple of copies of these styles.

[22:27:46.0000] <wanderview>
does that shadow DOM issue become worse with es module approach?  can it share a stylesheet in memory, but not dynamically inserted style?

[22:28:14.0000] <kochi>
if such style is static (e.g. <style>...</style> in <template>), Blink does optimization of sharing the stylesheet resource memory.  So if JS generates style for each shadow, they can't be shared.

[22:29:26.0000] <wanderview>
right

[22:29:54.0000] <wanderview>
we do that within a window as well I believe

[22:30:09.0000] <wanderview>
not sure if our shadow dom work takes advantage of it, though

[22:31:39.0000] <kochi>
If JS generates inline styles, I think caching is never expected for CSS?

[22:32:48.0000] <annevk>
Shadow DOM work in Gecko has not started yet I think, though there might be old patches

[22:33:09.0000] <annevk>
Custom elements is nearly there though

[22:33:20.0000] <kochi>
annevk: good to hear!

[22:34:31.0000] <Domenic>
Oh, I wasn't aware custom elements was happening

[22:34:50.0000] <kochi>
btw, "CSS in JS" Alex is talking about is probably https://speakerdeck.com/vjeux/react-css-in-js ?

[22:36:23.0000] <kochi>
and CE is https://bugzilla.mozilla.org/show_bug.cgi?id=889230 ?

[22:36:29.0000] <wanderview>
Domenic: I'm guessing you are not in NYC right now?

[22:36:35.0000] <Domenic>
wanderview: in Tokyo :)

[22:36:52.0000] <annevk>
Domenic: that's why Edgar files issues now and then 😊

[22:37:02.0000] <wanderview>
kochi: that looks like the right bug

[22:37:06.0000] <Domenic>
nice

[22:37:35.0000] <Domenic>
Still a long ways to go I guess https://bugzilla.mozilla.org/showdependencytree.cgi?id=889230&hide_resolved=1

[22:37:37.0000] <wanderview>
Domenic: are you going to be around the SW spec meeting next week?

[22:37:42.0000] <Domenic>
wanderview: yep!

[22:37:47.0000] <wanderview>
cool

[23:13:37.0000] <wanderview>
kochi: btw, I filed an issue with some questions I had around html imports and service workers: https://github.com/w3c/ServiceWorker/issues/1095

[23:13:46.0000] <wanderview>
just FYI in case you aren't watching that repo

[23:14:16.0000] <annevk>
domfarolino: https://medium.com/dev-channel/pretty-printing-d80639fb8881 is probably of interest

[23:17:43.0000] <domfarolino>
annevk: thanks a lot

[23:22:44.0000] <kochi>
wanderview: thanks for raising the question!

[23:23:21.0000] <kochi>
Usually I'm only watching github.com/w3c/webcomponents/

[02:27:02.0000] <wanderview>
kochi: are link.import documents considered an "active document"?

[02:27:35.0000] <wanderview>
for example, I think you can reference an iframe.contentWindow.document after doing iframe.remove()... but the document is not considered active any more

[02:28:09.0000] <wanderview>
the imported documents seem kind of like that because they are not rendered... but on the other hand they are associated with an environment settings object through the master document global

[02:29:38.0000] <kochi>
Does Gecko has the same notion as blink about "document is active"?

[02:30:08.0000] <wanderview>
kochi: hmm... I have no idea what blink does there :-)

[02:31:07.0000] <wanderview>
in gecko we can check to see if the document is associated with an environment settings object (gecko inner window) and a browsing context (gecko outer window + docshell)

[02:31:59.0000] <wanderview>
I think iframe.remove() just tears down the browsing context for the frame... but not 100% sure

[02:32:21.0000] <wanderview>
I know for bfcache we keep the environment settings object alive, but it doesn't have the browsing context associated

[02:33:54.0000] <kochi>
wanderview: okay, I assume we have similar notion - Blink  defines several lifecycle states of Document and e.g. if the document is being shutdown, it's inactive.

[02:36:11.0000] <kochi>
So as long as <link rel="import"> element is connected to the master document (directly or indirectly) the `link.import` is active.

[02:36:22.0000] <wanderview>
ok

[02:36:36.0000] <wanderview>
I guess it was kind of theoretical spec question

[02:37:04.0000] <wanderview>
I mean, currently an environment settings object has a single document in html spec

[02:37:23.0000] <wanderview>
but with html imports it kind of has a secondary list of documents in addition to its master document

[02:43:23.0000] <kochi>
okay, so an import can be in a state that can't happen for a  document created using DOMImplementation.creatHTMLDocument().

[02:45:22.0000] <wanderview>
I guess the assumption is that anything that uses spec language like "get the document for the given environment settings object" will be working with the master document... all the imported documents are invisible to these specs

[02:47:12.0000] <kochi>
oh, "active document" should be https://html.spec.whatwg.org/multipage/browsers.html#active-document in the spec world

[02:48:14.0000] <wanderview>
ok

[02:48:21.0000] <kochi>
I was meaning different "active", then.

[02:49:07.0000] <kochi>
The HTML spec says one browsing context has one active document.

[02:49:38.0000] <wanderview>
I guess conceptually the imported documents hang more off the master document and the environment settings/browsing context doesn't really know about them at all

[02:49:45.0000] <wanderview>
sorry, just thinking it through

[02:51:04.0000] <kochi>
no worries. in HTML imports world, wherever script runs, `window.document` is the master document.

[02:53:00.0000] <kochi>
To get a reference of imported document is to use `link.import` property, or (in script running inside import) `document.currentScript.ownerDocument` (or any node in the import as context object).

[03:37:21.0000] <annevk>
Domenic: so for HTML you pretty much s/character/code point/, or something else?

[03:38:09.0000] <annevk>
Domenic: there's currently 1849 matches for "character"

[03:39:22.0000] <Domenic>
annevk: hmm mostly, although I would focus on the instances where we're actually manipulating strings, not e.g. talking about the user typing.

[03:39:29.0000] <Domenic>
It sounds pretty thankless though

[03:39:39.0000] <Domenic>
Maybe not worth it

[03:41:30.0000] <annevk>
Domenic: maybe we should do it as some kind of ongoing effort whenever we refactor algorithms, just like we do with other Infra things

[03:42:43.0000] <annevk>
Domenic: it was pretty easy to avoid labels in the IPv6 parser btw, so I'm hopeful that we might not need them

[03:43:33.0000] <Domenic>
Ongoing effort sounds like a good idea, yeah.

[03:44:06.0000] <Domenic>
Labels does sound good. I want to implement that change in whatwg-url to check no test results change but yeah it was pretty reasonable.

[03:45:13.0000] <annevk>
I implemented it in whatwg-url as well to make sure, hopefully you'll find the same

[04:46:54.0000] <annevk>
zcorpan: GitHub can no longer display the fingerprint resource, claims it's invalid

[04:47:16.0000] <zcorpan>
annevk: fixing. damned namespaces

[04:47:52.0000] <annevk>
zcorpan: amateur hour

[04:48:10.0000] <annevk>
(not that I spotted that, was looking for a well-formedness error)

[04:49:45.0000] <annevk>
zcorpan: seems better to not have width="46" height="64" inside the SVG

[04:49:51.0000] <annevk>
zcorpan: viewBox should be enough

[04:50:29.0000] <annevk>
zcorpan: no other comments from though, thanks for taking it on

[04:50:58.0000] <zcorpan>
annevk: i figured this would be inlined and then it should have width/height there

[04:51:29.0000] <zcorpan>
annevk: the aria attributes are also only necessary when inline

[04:51:38.0000] <annevk>
zcorpan: I see, makes sense

[05:59:39.0000] <Domenic>
Oh, I thought we'd keep using <img>

[06:02:37.0000] <annevk>
Domenic: both solutions are fine with me, but it sounded like at least TabAtkins also wanted an inline solution

[06:02:48.0000] <Domenic>
Right, yeah, but we don't have to host one

[06:03:30.0000] <annevk>
Alright

[06:03:36.0000] <annevk>
zcorpan: does that work for you?

[06:04:56.0000] <zcorpan>
Domenic: annevk: yeah sure. TabAtkins just needs to add width/height/role/aria-label in bikeshed

[06:24:41.0000] <annevk>
Domenic: what other places can we reach out to about mutable strings?

[06:25:06.0000] <annevk>
Domenic: or should we just go ahead and start patching IDL?

[07:37:58.0000] <tobie>
Domenic: I just realized I completely forgot about the distinguishable algorithm which might also be affected. Did you consider it?

[07:59:26.0000] <tobie>
Domenic: updated the review with that comment.

[08:49:18.0000] <jyasskin>
kochi/wanderview: Note that ES "evaluation" actually happens in ~4 steps (per adamk), and IIRC 2 of them can happen before the full dependency graph is downloaded.

[08:49:50.0000] <jyasskin>
s/adamk/aklein/

[08:56:00.0000] <kochi>
jyasskin: yeah, load, instantiate, link, evaluate, iirc.

[08:58:14.0000] <kochi>
ah, maybe no? is "evaluate" further sub-divided?

[08:58:38.0000] <jyasskin>
Your stages sound like what I was thinking about.

[08:59:06.0000] <jyasskin>
Sorry for the noise then; you were already ahead of me. :)

[09:01:51.0000] <domfarolino>
Domenic: regarding the WPT to ensure the non-existence of timeline() and timelineEnd() in console, is there a reason to go with an html test rather than js? I ask bc you mentioned the suffix `-historical.html`

[09:24:21.0000] <annevk>
domfarolino: suspect Domenic is asleep, but -historical.any.js or some such should be fine too

[09:24:34.0000] <annevk>
(I suspect)

[09:40:18.0000] <domfarolino>
I'll go with that for now thanks

[10:13:54.0000] <domfarolino>
annevk: what does the `.any.` denote anyways?

[10:16:50.0000] <annevk>
domfarolino: dedicated worker and window

[10:17:08.0000] <domfarolino>
ah

[10:17:10.0000] <annevk>
domfarolino: http://web-platform-tests.org/writing-tests/testharness.html has documentation on it

[10:17:40.0000] <annevk>
domfarolino: you need some kind of prefix otherwise you won't get the boilerplate

[10:17:55.0000] <annevk>
domfarolino: jgraham has a patch for .window.js but I'm not sure if that has landed

[10:20:29.0000] <domfarolino>
Ah thank you!

[11:09:35.0000] <jgraham>
annevk: I think it did, bt I haven't checked

[12:06:18.0000] <ajeffrey_>
Got a question about https://html.spec.whatwg.org/multipage/embedded-content.html#iframe-load-event-steps

[12:06:46.0000] <ajeffrey_>
in particular "When the iframe's browsing context's active document is not ready for post-load tasks, and when anything in the iframe is delaying the load event of the iframe's browsing context's active document, and when the iframe's browsing context is in the delaying load events mode, the iframe must delay the load event of its document."

[12:07:18.0000] <ajeffrey_>
and how to interpret "anything in the iframe".

[12:07:57.0000] <ajeffrey_>
If there's a child iframe, and its currently active document contains a grandchild iframe,

[12:08:26.0000] <ajeffrey_>
do all the documents in the iframe's session history count?

[12:08:38.0000] <ajeffrey_>
or only the currently active document?

[12:09:00.0000] <gsnedders>
ajeffrey_: they wouldn't delay the active document's load event, would they?

[12:09:26.0000] <ajeffrey_>
gsnedders: that's what I'm trying to work out :)

[12:10:15.0000] <gsnedders>
/me wonders if the hotel wifi can cope with the HTML spec

[12:11:05.0000] <ajeffrey_>
the nasty case is something like if the grandchild loads a document A, then while it is still delaying the load, it navigates to B.

[12:13:32.0000] <gsnedders>
delaying the load event is linked to a document, AIUI

[12:14:11.0000] <ajeffrey_>
gsnedders: indeed, so what does "anything in the iframe" mean?

[12:14:17.0000] <gsnedders>
/me shrugs

[12:14:18.0000] <gsnedders>
:)

[12:14:26.0000] <ajeffrey_>
just the currently active docs?

[12:15:20.0000] <ajeffrey_>
(which means that traversing the history can change "delaying the load event" non-monotonically)

[12:15:38.0000] <ajeffrey_>
or all docs?

[12:16:10.0000] <ajeffrey_>
(which means we care about whether inactive docs are delaying the load event)

[12:16:26.0000] <ajeffrey_>
neither of these seem great.

[12:41:33.0000] <smaug>
does chrome have something like about:memory (in FF)

[12:45:06.0000] <gsnedders>
smaug: chrome://system/ I think is the most granuality you get

[14:25:39.0000] <jyasskin>
Is there any semi-standard set of github labels that folks are using? We're thinking of setting up a triage process of sorts for spec issues, and it'd be good to match other folks' labels.

[14:37:45.0000] <TabAtkins>
jyasskin: Check the CSSWG repo?

[14:38:09.0000] <TabAtkins>
https://github.com/w3c/csswg-drafts/labels

[14:38:21.0000] <TabAtkins>
In particular the "Needs X" set of labels

[14:40:50.0000] <jyasskin>
TabAtkins: Thanks. I also have https://github.com/w3c/webauthn/labels with some priority ones.

[15:18:51.0000] <tobie>
jyasskin: plh (from w3c) has been working on the following list: https://w3c.github.io/spec-labels.html

[15:21:49.0000] <tobie>
jyasskin: fwiw

[15:34:55.0000] <jyasskin>
tobie: That is exactly what I was looking for. Thank you!

[15:35:58.0000] <tobie>
jyasskin: np


2017-03-30
[17:27:43.0000] <KiChjang>
does anyone here have a good knowledge of chromium's development history?

[17:27:58.0000] <KiChjang>
i am particularly interested in chromium 28

[17:29:05.0000] <KiChjang>
and want to know whether it primarily used WebKit for the DOM stuff, and only managed the IPC and process framework differently

[19:11:23.0000] <wanderview>
/me wonders if JakeA is still on PTO.

[19:15:59.0000] <wanderview>
falken: ping

[19:19:53.0000] <falken>
wanderview: pong

[19:20:26.0000] <wanderview>
falken: hi!  I noticed an oddness in the WPT tests for client.navigate() and was wondering if chrome did the same here

[19:20:30.0000] <wanderview>
or if its a bug in firefox

[19:21:00.0000] <wanderview>
falken: it seems the test expects a cross-origin client.navigate() to reject... but I can't find where the spec says to do that: http://searchfox.org/mozilla-central/source/testing/web-platform/tests/service-workers/service-worker/resources/client-navigate-worker.js#46

[19:21:14.0000] <falken>
wanderview: I can run Chrome on the test. Which tests should I try?

[19:21:25.0000] <wanderview>
falken: its client-navigate.https.html

[19:21:43.0000] <wanderview>
maybe you have an expected pass/fail for it already?

[19:21:57.0000] <wanderview>
I think the test might be wrong

[19:22:43.0000] <falken>
wanderview: We are skipping the test for various reasons

[19:22:45.0000] <falken>
https://bugs.chromium.org/p/chromium/issues/detail?id=658997#c13

[19:23:38.0000] <falken>
Not too sure the conclusion of the comment but it looks like shimazu@ was also unsure about the rejection.

[19:24:14.0000] <falken>
Let me try to find the history of this test

[19:24:24.0000] <wanderview>
falken: looking at the spec: https://w3c.github.io/ServiceWorker/#client-navigate

[19:24:41.0000] <wanderview>
all I see is: "HandleNavigate: Navigate browsingContext to url with exceptions enabled. The source browsing context must be browsingContext."

[19:24:51.0000] <wanderview>
but I don't think that throws an exception for cross-origin url

[19:25:08.0000] <wanderview>
the navigate steps are a bit confusing to me, though

[19:26:01.0000] <wanderview>
and then later in step 10 the client.navigate() algorithm handles the cross-origin case by resolving null instead of a WindowClient object

[19:26:37.0000] <wanderview>
falken: I can write a small test site and see what chrome does...

[19:26:56.0000] <wanderview>
and I can fix the test if its broken

[19:27:45.0000] <falken>
Sure. I'm trying to see where the test came from.

[19:28:02.0000] <wanderview>
falken: then test came from here: https://bugzilla.mozilla.org/show_bug.cgi?id=1218148

[19:28:24.0000] <falken>
Ah, thanks.

[19:28:38.0000] <wanderview>
I think its just a bug we introduced and codified in the test

[19:28:57.0000] <falken>
Our navigate() tests are here: https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/serviceworker/windowclient-navigate.html

[19:29:37.0000] <wanderview>
falken: ok... looks like chrome does what the spec says then: https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/serviceworker/windowclient-navigate.html?l=51

[19:29:55.0000] <falken>
Agreed, we seem to expect the promise to resolve with undefined

[19:30:26.0000] <falken>
Sorry, null

[19:31:35.0000] <falken>
By the way, what's the easiest way to run the WPT tests against Firefox? Sometimes we have similar questions.

[19:31:57.0000] <falken>
Hopefully without needing to checkout/build Firefox.

[19:32:04.0000] <wanderview>
falken: thats a good question... I usually run it from a local build which is not convenient if your not working on it

[19:32:32.0000] <wanderview>
falken: I think there is a way to run WPT tests in a local web server and just point the browser at it though... maybe Domenic knows?

[19:32:45.0000] <Domenic>
You do ./serve inside a clone of WPT

[19:33:03.0000] <Domenic>
You may have to modify your /etc/hosts as per the WPT readme first depending on what tests you are running

[19:33:05.0000] <wanderview>
Domenic: do you have to clone git sub-repo's and stuff?

[19:33:14.0000] <Domenic>
hmm yeah I guess so

[19:33:22.0000] <wanderview>
ok

[19:33:30.0000] <Domenic>
https://github.com/w3c/web-platform-tests#running-the-tests

[19:33:42.0000] <wanderview>
falken: thanks for your help! saved me some time hunting things down

[19:33:52.0000] <falken>
np thanks

[19:34:30.0000] <kochi>
I can't access any w3.org sites. Are they offline?

[19:36:22.0000] <JakeA>
wanderview: I'm working today & tomorow

[19:37:15.0000] <wanderview>
JakeA: well, in this case you successfully delayed until falken answered my question :-)

[19:42:54.0000] <wanderview>
falken: here is the bug to fix client.navigate() and the test: https://bugzilla.mozilla.org/show_bug.cgi?id=1351935

[19:44:40.0000] <domfarolino>
Domenic: do you think it is worth opening up a chromium issue for the removal of timeline/timelineEnd or is Paul saying they're comfortable getting rid of it enough?

[19:45:10.0000] <domfarolino>
reason I'm asking here and not the thread is because didn't feel it was worth firing off 6 unnecessary emails for

[19:48:36.0000] <botie>
i already had it that way, chatter29.

[19:50:54.0000] <wanderview>
JakeA: what is the count on number of people for the meeting next week?  my impression is it will be quite large

[19:54:06.0000] <wanderview>
kochi: w3.org seems to load for me

[19:54:27.0000] <domfarolino>
is loading for me now too, wasn't earlier though for a bit

[20:23:11.0000] <JakeA>
wanderview: around 30!

[20:23:19.0000] <wanderview>
woah

[20:29:53.0000] <kochi>
ah, I can load w3.org now. was just flaky.

[20:30:37.0000] <Domenic>
domfarolino: I think it'd be good, you can cc paul there

[20:31:26.0000] <JakeA>
wanderview: I'm spending today and tomorrow figuring out an agenda. Will be interesting to see how much of the room is spectating and how much actively contributes. I'm going to try and keep it informal, but invite people to raise hands if they don't feel heard

[20:31:54.0000] <wanderview>
cool

[21:29:54.0000] <MikeSmith>
30 people is a lot for this kind of meeting

[21:31:18.0000] <MikeSmith>
kochi: about w3.org services/sites there as some kind of hiccup earlier but it seems to have been rectified

[21:32:24.0000] <kochi>
MikeSmith: thanks, I can access them now.

[21:33:21.0000] <MikeSmith>
ok

[21:34:10.0000] <MikeSmith>
not sure what the problem was but maybe just MIT doing maintenance during “off” hours

[21:34:30.0000] <MikeSmith>
which aren’t “off” hours for us of course

[00:01:19.0000] <annevk>
Seems like there's almost no tests for ancestorOrigins (apart from some IDL stuff) and testharness.js relies on it, good times

[00:01:44.0000] <annevk>
I hope it doesn't rely on it in a way that makes changing its behavior problematic

[00:12:43.0000] <wanderview>
JakeA: so the changes that introduce FetchEvent.reservedClientID also introduce the possibility that FetchEvent.clientID is non-null for navigations

[00:13:00.0000] <wanderview>
JakeA: do you think we should keep forcing FetchEvent.clientID to be null until reservedClientID is implemented?

[00:13:26.0000] <wanderview>
my current work can actually start providing FetchEvent.clientID, but I'm not ready to expose reservedClientID yet... just wondering what would be best for devs

[00:15:58.0000] <JakeA>
wanderview: I think you're right, we should aim to keep clientId null until reservedClientId is implemented, then there's always a way to detect a potentially-client-making request

[00:16:07.0000] <JakeA>
*scratches head* does that make sense?

[00:16:13.0000] <wanderview>
JakeA: yea, thanks

[00:16:45.0000] <JakeA>
Thanks for all the issues on the client stuff btw, and sorry I haven't responded to many of them

[00:16:56.0000] <JakeA>
Hopefully we can chew through them all on Monday/Tuesday

[00:20:03.0000] <Domenic>
/me checks... it is spelled clientId, with a lowercase "d". Phew.

[00:27:47.0000] <tobie>
annevk: looking at the testharness.js PR you just filed, I think I wrote this this code and the related comment ( a *while* ago).

[00:28:54.0000] <annevk>
tobie: yeah, Safari only recently fixed this

[00:29:04.0000] <annevk>
testharness.js could really do with some triage

[00:29:20.0000] <annevk>
lots of PRs without a clear signal

[00:29:22.0000] <tobie>
annevk: testharness needs a test suite of its own for a start

[00:29:40.0000] <annevk>
That would be nice...

[00:41:16.0000] <tobie>
Domenic: latest PR changes look good.

[00:42:25.0000] <tobie>
Domenic: you backed out of the [TreatNullAsEmptyString] change in the PR, but we'll still need to get [TreatAsNull] rewritten as type extended attributed, no?

[00:43:37.0000] <tobie>
Domenic: I didn't have coffee this morning and it shows. :-/

[00:44:48.0000] <tobie>
Domenic: What I meant is that we'll still need to rewrite specs that use [TreatAsNull] on an attribute to use it on the type instead, correct?

[00:45:38.0000] <tobie>
Domenic: if so, what was your reasoning in backing out of the [TreatNullAsEmptyString]?

[00:46:18.0000] <annevk>
tobie: note that Bikeshed also autolinks TreatNullAs: https://dom.spec.whatwg.org/#interface-domimplementation

[00:46:30.0000] <annevk>
(not TreatAsNull)

[00:47:13.0000] <tobie>
annevk: lol, looks like I'm not the only one mixing this up. :D

[00:48:46.0000] <annevk>
If we're going to simplify, I'd almost argue for [NullIsEmptyString], but...

[00:50:18.0000] <wanderview>
Domenic: but we have ServiceWorker.scriptURL... seems like .clientID would be consistent with that...

[00:50:40.0000] <wanderview>
we should probably just follow whatever XMLHttpRequest did...

[00:51:16.0000] <wanderview>
we can take a few hours next week to sort out the acronyms

[00:53:55.0000] <annevk>
wanderview: no, please be consistent with https://w3ctag.github.io/design-principles/#casing-rules

[00:55:14.0000] <tobie>
wanderview: see https://w3ctag.github.io/design-principles/#casing-rules

[00:55:43.0000] <tobie>
arg, annevk beat me to it.

[01:03:30.0000] <Domenic>
tobie: my reasoning was because separate PRs make sense as you said.

[01:03:45.0000] <Domenic>
Some specs might not need rewriting; mostly if they use optional they would

[01:04:21.0000] <Domenic>
wanderview: "id" is short for "identity" not "I Dentity"

[01:05:05.0000] <wanderview>
/me learns not to joke about acronyms in this channel.

[01:10:48.0000] <Domenic>
Well, I figured the XHR was a joke... but the first sentence I wasn't so sure :)

[01:23:48.0000] <tobie>
wanderview: did I mention I didn't have coffee this morning yet?

[01:25:42.0000] <tobie>
Domenic: I agree separate PRs generally make more sense, but then if this a lot of intersection between the rewriting both PRs imply for specs, it might have made sense to keep them together nonetheless.

[01:26:07.0000] <tobie>
Domenic: you seem to suggest that's not really the case, so we're good like this.

[01:26:46.0000] <annevk>
Domenic: what do you think about my first child rewording suggestion?

[01:26:52.0000] <annevk>
Domenic: I can create a PR

[01:27:15.0000] <Domenic>
annevk: meh, yeah, I guess I can sign off on PRs, but not a big deal IMO. Be sure to catch all three places the term is used.

[01:28:08.0000] <annevk>
Domenic: I read it the same as chaals did

[01:28:41.0000] <annevk>
I can mark it editorial so nobody is in the wrong :p

[01:29:38.0000] <Domenic>
:)

[01:33:57.0000] <wanderview>
tobie: np

[01:34:13.0000] <wanderview>
falken: has chrome implemented the byte-for-byte comparison of importScripts() yet?

[01:34:24.0000] <falken>
wanderview: I'm sorry, no we haven't.

[01:34:49.0000] <wanderview>
falken: ok, np... I'm just reviewing our WPT test for the feature and was curious if I could run it against chrome

[01:34:52.0000] <falken>
https://bugs.chromium.org/p/chromium/issues/detail?id=648295

[03:38:16.0000] <annevk>
beverloo: https://github.com/w3c/web-platform-tests/pull/5188

[03:39:39.0000] <beverloo>
ack, let me reply

[03:42:08.0000] <beverloo>
annevk, replied

[03:43:32.0000] <beverloo>
annevk, unrelated question, how'd I go about getting approval for https://github.com/w3c/web-platform-tests/pull/5094?

[03:44:18.0000] <annevk>
beverloo: if you get a review for that PR I can land it

[03:44:53.0000] <beverloo>
cool, thanks, I'll nag Jake

[05:29:21.0000] <tobie>
beverloo/annevk: so much boilerplate ffs

[05:41:21.0000] <annevk>
tobie: could use any.js, agreed, no need to swear about it though 😊

[05:41:53.0000] <annevk>
Although I suppose that does not work for sw yet

[05:42:20.0000] <tobie>
annevk: to be clear, I was complaining about the state of things, not the PR

[05:43:17.0000] <tobie>
annevk: I don't know what any.js is, btw. Pointer?

[05:43:44.0000] <tobie>
annevk: I r+ the PR, btw. Do you want to merge it or shall I?

[05:44:17.0000] <annevk>
tobie: search for it on http://web-platform-tests.org/writing-tests/testharness.html

[05:44:29.0000] <tobie>
annevk: ty

[05:44:32.0000] <annevk>
tobie: I guess you can merge it, but if it can use .any.js that might be nice to do before landing

[05:48:28.0000] <tobie>
annevk: unclear from the doc

[05:48:40.0000] <tobie>
will check in #testing

[07:20:58.0000] <zcorpan>
TabAtkins: any ETA on the fingerprinting thing in bikeshed?

[09:10:38.0000] <jugglinmike>
JakeA: hello! Do you have a minute for a quick question about contributing to the Service Worker spec?

[09:11:33.0000] <jugglinmike>
I'm trying to learn how "terms defined by reference" are included in the `index.bs` file.

[09:11:56.0000] <jugglinmike>
I'm confused because I'm not seeing any entries for, e.g. "transforming"

[09:12:25.0000] <jugglinmike>
Does the Bikeshed utility have W3C references built in?

[09:13:37.0000] <annevk>
jugglinmike: oh, yes, it does

[09:14:14.0000] <annevk>
jugglinmike: there's a tool that collects all these terms from various documents and puts them in a central database

[09:14:27.0000] <annevk>
jugglinmike: not all standards are included, but the important ones are

[09:14:56.0000] <jugglinmike>
annevk: ah. I only just found https://tabatkins.github.io/bikeshed/ . Reading more about this now

[09:33:07.0000] <jugglinmike>
TabAtkins: I'm having some issues with Bikeshed, wondering if you can help. `bikeshed refs --text=transforming` returns successfully, but `bikeshed refs --spec promises-guide-1` crashes with "TypeError: coercing to Unicode: need string or buffer, NoneType found"

[09:33:37.0000] <jugglinmike>
running Python 2.7.12 in Ubuntu, installed according to the instructions published online

[09:34:09.0000] <TabAtkins>
Hm, that works for me, and I haven't changed anything about it in some time.

[09:34:19.0000] <TabAtkins>
When did you install? Was it a while ago?

[09:34:47.0000] <jugglinmike>
about an hour ago

[09:34:49.0000] <jugglinmike>
however

[09:35:15.0000] <TabAtkins>
Hm!

[09:35:23.0000] <jugglinmike>
oh, and this is obviously not a good idea:

[09:35:31.0000] <jugglinmike>
I am running at commit https://tabatkins.github.io/bikeshed/#installing

[09:35:35.0000] <jugglinmike>
that's not a sha

[09:35:42.0000] <jugglinmike>
I am running at commit 0466dfe0603d05075d063d910336a5796413ac9b

[09:36:25.0000] <jugglinmike>
because that is the commit used to build the latest version of the ServiceWorker specification, and Bikeshed at `master` crashes on build

[09:37:05.0000] <TabAtkins>
So the bug you're running into has been fixed since that commit.  I appreciate being told when master is crashing on a spec. ^_^

[09:37:06.0000] <jugglinmike>
I should have thought of this, but probably something has changed about the format of the external database in the time since the commit I am using

[09:37:10.0000] <annevk>
I thought JakeA had fixed ServiceWorker somehow, but I guess it regressed again :-/

[09:37:34.0000] <TabAtkins>
Nothing about the db, it's about the querying function - it previously required a --text parameter accidentally.

[09:37:34.0000] <annevk>
TabAtkins: it seems like it crashes on ServiceWorker

[09:37:37.0000] <jugglinmike>
TabAtkins: I figured you might. I have been trying to get it working so that the issue I file is cogent

[09:37:51.0000] <annevk>
TabAtkins: cd ServiceWorker/docs

[09:37:55.0000] <annevk>
TabAtkins: bikeshed

[09:38:00.0000] <TabAtkins>
Meh, "shit is crashing, here's the repo/file" works *great* as an issue for me, fyi

[09:38:05.0000] <annevk>
TabAtkins: KeyError: 'biblio'

[09:38:30.0000] <jugglinmike>
in that case, annevk has you covered ^

[09:38:33.0000] <annevk>
I guess I can let jugglinmike file, though really jungkees or JakeA should have done this

[09:38:44.0000] <jugglinmike>
I don't mind filing

[09:38:52.0000] <jugglinmike>
It'll give me something to show for the morning :P

[09:39:05.0000] <TabAtkins>
Checking it out now, gimme a sec.

[09:39:17.0000] <annevk>
I guess they haven't done anything for 28 days, maybe that's why stuff went weird

[09:45:26.0000] <jugglinmike>
here's all I know https://github.com/tabatkins/bikeshed/issues/968

[09:45:37.0000] <TabAtkins>
I found the error, fixing it now.

[09:47:39.0000] <TabAtkins>
And done.

[09:48:12.0000] <TabAtkins>
Thanks for the report, I'd left out one of the linktypes from a list, so it was throwing a KeyError when I went to look for it. ^_^

[09:49:54.0000] <jugglinmike>
Awesome, thanks TabAtkins!

[09:50:04.0000] <TabAtkins>
Crashes mean I've definitely done something wrong, and it's usually much easier for me to diagnose it than for you to, so feel free to file an issue *immediately* when it happens. All I need is a file I can repro the crash with, I'll take care of the rest.

[09:50:14.0000] <jugglinmike>
Roger that

[09:50:52.0000] <jugglinmike>
Now I have a workflow question. Might be better for Jake, but maybe you can speak to how this is generally handled by Bikeshed users

[09:52:02.0000] <jugglinmike>
Re-generating the spec using `master` causes changes to the document that are unrelated to my patch. Should I pick around those for my pull request? Or maybe make a dedicated commit for them before introducing my changes/

[09:52:27.0000] <jugglinmike>
(And do many people check the compiled document into their repository?)

[09:52:58.0000] <TabAtkins>
Up to you. Presumably they're formatting or other minor things?  Eyeballing the changes is usually good just to make sure everything's still generating fine.

[09:53:30.0000] <TabAtkins>
imo, either check the generated file in, or have a CI job that compiles for you and checks it in somewhere else.

[09:54:30.0000] <jugglinmike>
yeah, I'd prefer the latter. But I'm just some guy

[09:55:47.0000] <annevk>
jugglinmike: yeah, service workers should setup tooling so you only need to modify .bs

[09:56:17.0000] <annevk>
jugglinmike: but until they do, including the generated HTML is generally the way to go, although it creates more rebasing hassle than you want

[09:58:39.0000] <jugglinmike>
I think I'll pick it out and submit it separately. The annoying thing about this is the "last updated" information. It guarantees merge conflicts

[10:00:02.0000] <annevk>
jugglinmike: at that point you shouldn't include it at all

[10:00:13.0000] <annevk>
jugglinmike: you don't want to mess with generated output

[14:50:48.0000] <JakeA>
annevk: happy to set up a bot to build the spec. Who's doing this already? Is there a best-practice config?


2017-03-31
[18:51:58.0000] <wanderview>
JakeA: your triage of all the issues is triggering my OCD to reply to all of them

[18:52:54.0000] <JakeA>
wanderview: haha I'm trying not to look at replies until I've gone through all the open issues

[18:53:08.0000] <JakeA>
but yeah, I'm struggling

[18:53:15.0000] <JakeA>
"ohh look, an email!"

[18:59:01.0000] <wanderview>
shiny

[19:34:53.0000] <wanderview>
JakeA: btw... making our "what have we been doing" book report slides... trying to keep it to 3 slides so its short

[20:14:05.0000] <JakeA>
wanderview: that's ideal. Brief is best I think. Facebook are going to give an update too

[21:39:15.0000] <annevk>
JakeA: most WHATWG standards do this

[21:46:37.0000] <JakeA>
ta

[22:23:43.0000] <wanderview>
JakeA: is background fetch behind a pref or an origin trial?

[22:24:39.0000] <JakeA>
wanderview: right now, neither. A very limit, not-really-usable thing will hit Canary in a couple of days. It's intended to be an origin trial when it's usable

[22:24:50.0000] <wanderview>
ah, ok

[22:24:56.0000] <JakeA>
Need API review & a spec, of course

[22:24:58.0000] <wanderview>
I saw the chromium issue update this morning... was just wondering

[22:24:59.0000] <JakeA>
The spec is just IDL right now

[22:25:23.0000] <JakeA>
I hear vague rumblings that Alex isn't happy with my design :D

[22:25:53.0000] <wanderview>
ha

[22:25:57.0000] <JakeA>
But we're going to chat it through, hopefully before the f2f

[23:04:21.0000] <wanderview>
Domenic: are there any DOM bindings that use WritableStream yet?  or included in your intent-to-ship?

[23:38:23.0000] <Domenic>
wanderview: not at this time. Mainly we want to allow the ecosystem of developer-created writable streams to kick off. Platform APIs really want transform streams and we figured it was better to ship incrementally instead of holding out for a big writable + transform + piping + streaming textdecoder bonanza.

[23:38:41.0000] <wanderview>
cool

[23:39:38.0000] <wanderview>
yea, I'm a little annoyed we can't ship ReadableStream without fetch body support... afraid people will just feature detect ReadableStream in the global and not actually body attribute being present

[23:39:58.0000] <wanderview>
so happy to see them ship separately

[23:46:37.0000] <Domenic>
Oh, that is a shame, sorry about that :-/

[23:47:13.0000] <wanderview>
Domenic: good news, though, is till is looking to land ReadableStream js bits in next couple weeks

[23:47:23.0000] <wanderview>
so we can start on the binding layer

[23:48:48.0000] <Domenic>
Very excited :)

[23:58:24.0000] <JakeA>
wanderview: I've dumped & loosely categorised issues at https://github.com/w3c/ServiceWorker/issues/1053. I might reduce it a bit & prioritise

[23:59:11.0000] <wanderview>
JakeA: wow, nice!

[00:04:33.0000] <wanderview>
JakeA: you probably deserve a beer after doing that

[00:12:14.0000] <wanderview>
annevk: is there any discussion about any other browser seriously considering switching to safari's double-keying approach?

[00:12:20.0000] <wanderview>
I haven't seen it... but maybe I am missing it

[00:52:53.0000] <annevk>
wanderview: dunno, but we need to solve for all browsers to be successful

[00:53:24.0000] <annevk>
wanderview: I definitely think Fx should strongly consider it given our messaging on privacy

[01:58:24.0000] <JakeA>
annevk: wanderview: going to bring up foreign fetch in the context of this. It might require big changes

[01:59:46.0000] <wanderview>
JakeA: context of what?

[02:00:23.0000] <JakeA>
wanderview: sorry, the double-keying

[02:00:39.0000] <wanderview>
JakeA: oh, right... yea... we're totally talking about foreign fetch here :-)

[02:00:40.0000] <JakeA>
Since foreign fetch kinda makes it not work

[02:01:16.0000] <wanderview>
I don't think that is the case... foreign fetch just gets a storage location that is less likely to be shared

[02:01:41.0000] <wanderview>
but thats the whole goal of double-keying... seems like its a purposeful tradeoff to me

[02:03:20.0000] <wanderview>
JakeA: anyway, I should probably just google fight this fight... I don't think firefox won't be implementing foreign fetch any time soon

[02:06:17.0000] <wanderview>
if safari implements storage de-duplication it may not even be that bad

[02:06:21.0000] <wanderview>
or less effective

[02:12:05.0000] <JakeA>
Yeah, deduping would make things less bad

[03:20:45.0000] <annevk>
I think it can actually be reasonable if you do de-duping and if first-party visits don't result in later double-keying, which is what Safari does for cookies as I understand it, but not all kinds of storage

[03:21:23.0000] <annevk>
But it would be nice if we worked through it first and agreed on some kind of model so developers end up with a more predictable platform

[03:45:14.0000] <wanderview>
JakeA: I wrote a new SW issue in order to make your life more complicated: https://github.com/w3c/ServiceWorker/issues/1100

[03:50:26.0000] <ondras>
what is the current status re. xhr.send(arrayBuffer) vs. xhr.send(arrayBufferView) ?

[03:50:41.0000] <annevk>
ondras: both should work

[03:51:16.0000] <ondras>
annevk: desktop browsers are okay with both (I saw somewhere that they should warn when using ArrayBuffer?), older androids (<4.4) seem to not work with ArrayBufferView

[03:51:20.0000] <ondras>
is there a preferred version?

[03:52:36.0000] <ondras>
https://fetch.spec.whatwg.org/#concept-bodyinit-extract

[03:52:50.0000] <ondras>
annevk: what exactly is BufferSource here? is that an AB/ABV ?

[03:53:16.0000] <ondras>
a-ha! https://heycam.github.io/webidl/#BufferSource

[03:54:59.0000] <annevk>
ondras: there's no preference

[03:55:12.0000] <ondras>
annevk: I see. This pages states otherwise: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send

[03:55:17.0000] <ondras>
so probably mdn is outdated?

[03:56:00.0000] <annevk>
ondras: yeah, someone should probably fix that

[03:56:28.0000] <ondras>
annevk: cool, thanks for the info. .buffer will apparently fix my android issue then.

[03:57:26.0000] <annevk>
ondras: note that using .buffer can be tricky, since a view can be for only part of an ArrayBuffer, so might represent only a subset of the bytes, if you are then passing .buffer you'd potentially pass more

[03:58:20.0000] <ondras>
annevk: yeah, I am sending new Uint8Array(plain-number-array).buffer

[03:58:25.0000] <ondras>
so these should be equal

[04:48:46.0000] <zcorpan>
annevk: ....what happened here? https://github.com/whatwg/html/pull/2420

[04:53:47.0000] <Domenic>
zcorpan: it has zero commits, and it's toward some other branch... I wonder if there's a GitHub bug that auto-merges zero-commit PRs or something

[05:25:40.0000] <annevk>
zcorpan: not sure, first time I see it

[05:27:45.0000] <zcorpan>
So for the fingerprint, should we wait for bikeshed or try to merge the current set of PRs?

[05:28:33.0000] <annevk>
I'm happy to wait for bikeshed / TabAtkins

[05:28:37.0000] <annevk>
Or is something blocked?

[05:29:48.0000] <zcorpan>
Don't think so. OK

[05:30:59.0000] <annevk>
I found out WebAssembly is using OCaml for its spec/reference implementation

[05:31:27.0000] <annevk>
I wonder if that caught Philip`'s attention yet

[05:43:38.0000] <Philip`>
It hadn't

[05:43:50.0000] <Philip`>
They should have written the reference implementation in WebAssembly, though

[05:44:05.0000] <annevk>
heh

[05:44:06.0000] <Philip`>
because who doesn't like writing assembly code?

[05:45:24.0000] <Philip`>
(Besides, only weirdos use OCaml)

[06:57:42.0000] <SimonSapin>
jgraham: what’s the review/merge process for wpt? Click the green button once Travis is happy?

[06:58:08.0000] <gsnedders>
jgraham: a) find someone to review it, if it's not already been publicly reviewed

[06:58:14.0000] <gsnedders>
wait, SimonSapin even, not jgraham  ^^

[06:58:24.0000] <SimonSapin>
gsnedders: I’m reviewing

[06:58:26.0000] <gsnedders>
SimonSapin: b) hit the green button once Travis is happy and a) is done

[07:22:05.0000] <tobie>
SimonSapin: https://github.com/w3c/web-platform-tests#test-review

[07:22:29.0000] <SimonSapin>
thanks

[07:22:51.0000] <tobie>
(for future reference)

[07:40:42.0000] <jugglinmike>
JakeA is there any information published online about the April face-to-face meeting/

[07:44:46.0000] <annevk>
jugglinmike: https://github.com/w3c/ServiceWorker/issues/1053

[07:45:16.0000] <jugglinmike>
perfect, annevk. Thanks!

[08:07:36.0000] <annevk>
Philip`: I'm somewhat surprised they're doing it on OCaml too, but the person writing the standard is a big fan of functional programming

[08:08:33.0000] <annevk>
Philip`: judging from https://c10109cf-a-62cb3a1a-s-sites.googlegroups.com/site/mlworkshoppe/2016-1.pdf it sounds like not many other people understood it

[08:29:36.0000] <annevk>
JakeA: maybe discuss https://github.com/whatwg/html/issues/151 next week too

[09:37:45.0000] <TabAtkins>
annevk: I'd appreciate a definition to link to for the fingerprint stuff.

[09:41:09.0000] <annevk>
TabAtkins: https://github.com/whatwg/infra/pull/115 is the PR to add one, but it kinda depends on a change to Bikeshed (and I'd also like Domenic to review it)

[09:41:25.0000] <annevk>
TabAtkins: so we might have a deadlock of sorts 😊

[09:42:06.0000] <TabAtkins>
That is not actually blocked by me in any way.

[09:46:25.0000] <annevk>
TabAtkins: zcorpan said it was

[09:47:08.0000] <annevk>
TabAtkins: the added "Fingerprint Image:" metadata probably doesn't work without changes to Bikeshed?

[09:47:36.0000] <TabAtkins>
Right, which he doesn't need to just add a definition.

[09:48:48.0000] <annevk>
TabAtkins: so your proposal is that we first add some text and link to the image ourselves and then later update that with bikeshed?

[09:49:17.0000] <annevk>
TabAtkins: moving Bikeshed first and then landing this seems easier to me

[09:49:59.0000] <TabAtkins>
Or don't use bikeshed magic on the definition.

[09:50:24.0000] <TabAtkins>
But bikeshed really does need something to link to before I can land anything.

[09:50:31.0000] <annevk>
But it's kinda the point of the definition to demonstrate how it materialises

[09:51:27.0000] <annevk>
TabAtkins: how about you create a PR for bikeshed that uses https://infra.spec.whatwg.org/#fingerprinting-vector and then we coordinate landing next week?

[09:51:53.0000] <TabAtkins>
Sure. 😀

[14:12:24.0000] <TabAtkins>
Quick poll: In <https://drafts.css-houdini.org/css-typed-om/#dom-css-hz> I have a bunch of functions for constructing CSS unitted values. I'm spelling Hz() and kHz() properly - worth it, or should I lowercase them, since CSS doesn't care about casing?

[14:13:34.0000] <gsnedders>
TabAtkins: how do authors mostly write them?

[14:13:43.0000] <gsnedders>
I mean I guess they don't because they're scarcely used

[14:13:47.0000] <TabAtkins>
I have no idea, since they're only used in Speech.

[14:14:07.0000] <gsnedders>
Indeed.

[15:07:10.0000] <JakeA>
annevk: shall do

[15:23:01.0000] <tobie>
TabAtkins: Use the correct casing. (That's what we'll do with sensors if we end up exposing units.)

[15:23:09.0000] <TabAtkins>
+1