2015-07-01
[21:02:30.0000] <Domenic>
Anyone with latest Safari mind testing if Array.prototype.includes is present?

[21:05:37.0000] <Domenic>
Also Uint8Array.prototype.includes

[21:10:20.0000] <tantek>
Safari 6.1.6 returns undefined for both

[21:11:06.0000] <Domenic>
Sorry, should have specified I was looking for Safari 8 and 9

[22:27:23.0000] <miketaylr>
Domenic: neither in Safari 8.0.5

[22:27:43.0000] <Domenic>
I have reports of it being in 8.1

[22:47:44.0000] <terinjokes>
Domenic: 8.1 here

[22:48:51.0000] <terinjokes>
Array.prototype.includes 👍, Uint8Array.prototype.includes 👎

[01:30:17.0000] <annevk_>
JakeA: I guess we could revisit the new Request() aspect of fetch(), if someone has the time, though that still leaves open what new Request() should do

[01:31:26.0000] <JakeA>
annevk: I'm not suggesting it's wrong, just couldn't work out why it was different

[01:32:09.0000] <annevk>
JakeA: so request has a pointer to a stream; then you create a new request that then gets to own that stream

[01:32:31.0000] <annevk>
JakeA: the old request now no longer has a pointer to a stream, sure, the used flag can be set, but body would be null

[01:32:54.0000] <annevk>
JakeA: and then you get into the thing what null body should mean...

[01:34:35.0000] <JakeA>
annevk: ahh, I thought new Request(request) would create a new stream that read from the original request stream

[01:34:41.0000] <JakeA>
your way is more efficient

[02:00:32.0000] <Domenic>
/me has been reading too much C++... this is basically auto_ptr vs. shared_ptr

[02:01:13.0000] <Domenic>
I am not sure what the use case is for a "copy constructor" for Request anyway?

[02:26:06.0000] <annevk>
Domenic: mostly to normalize the request

[02:26:16.0000] <annevk>
Domenic: while making sure we don't forget anything

[02:26:48.0000] <Domenic>
In what case can a Request be un-normalized?

[02:27:53.0000] <annevk>
Domenic: the one passed to FetchEvent

[02:28:44.0000] <annevk>
Domenic: (and anything passed to FetchEvent that's then passed to cache.put())

[02:28:45.0000] <Domenic>
annevk: how did the author generate an un-normalized Request to pass to FetchEvent though?

[02:28:55.0000] <annevk>
Domenic: the UA did

[02:29:10.0000] <Domenic>
annevk: why would the UA do something seemingly crazy like that?

[02:29:41.0000] <annevk>
Domenic: it's not crazy, it reflects the settings for the document, but not all of those can be used for the service worker, so you need a reset of sorts before you go to the network

[02:29:55.0000] <annevk>
Domenic: the document/worker/shared worker*

[02:30:36.0000] <Domenic>
Hmm. I don't really understand, but I'll take your word for it...

[02:31:19.0000] <annevk>
Domenic: e.g. the client of a request passed to FetchEvent will be the document/worker

[02:32:00.0000] <annevk>
Domenic: but the request resulting from fetch() should always have a client that is the global environment

[02:32:10.0000] <annevk>
Domenic: there's a ton of stuff like that

[02:32:15.0000] <Domenic>
hmm

[02:32:49.0000] <annevk>
/me refers back to his Twitter rant about not enough people understanding what is going on

[02:33:25.0000] <jochen__>
hey annevk Domenic :)

[02:33:30.0000] <jochen__>
so what about the promise rejection events?

[02:33:38.0000] <annevk>
hahaha

[02:33:56.0000] <jochen__>
do you think mozilla will implement them?

[02:33:59.0000] <annevk>
Oh, wait, I thought you said cancelation

[02:34:12.0000] <annevk>
bz seemed open to implementing them

[02:34:30.0000] <jochen__>
would be cool to get some feedback on the current spec

[02:34:38.0000] <annevk>
I didn't really follow that thread admittedly

[02:34:41.0000] <annevk>
jochen__: pointer?

[02:34:42.0000] <jochen__>
impl. in blink is done % feedback from other vendors

[02:34:59.0000] <jochen__>
https://github.com/domenic/unhandled-rejections-browser-spec

[02:35:08.0000] <jochen__>
+ the three pull requests from me :)

[02:35:13.0000] <Domenic>
jochen__: I need to update for https://github.com/domenic/unhandled-rejections-browser-spec/issues/2#issuecomment-113226244

[02:35:23.0000] <Domenic>
it seems like this is a new phase after microtasks

[02:35:41.0000] <annevk>
https://github.com/domenic/unhandled-rejections-browser-spec/issues/1 seems important

[02:36:02.0000] <Domenic>
Sigh, I should do that too, it's just so much less exciting

[02:36:18.0000] <jochen__>
#1 is spec'd and implemented, so just close it?

[02:36:23.0000] <Domenic>
To be clear, it's about *Worker objects having .onunhandledrejection etc.

[02:36:28.0000] <Domenic>
No, #1 is not specced or implemented

[02:36:49.0000] <Domenic>
Worker global scopes have the events. Worker objects do not yet.

[02:36:57.0000] <jochen__>
ah

[02:37:06.0000] <jochen__>
not sure that's desirable

[02:37:06.0000] <annevk>
"Environment settings object seems to be a place to dump stuff?" sounds about right

[02:37:13.0000] <Domenic>
haha

[02:37:26.0000] <jochen__>
that would require dispatching the events cross process

[02:37:43.0000] <Domenic>
jochen__: yeah, it's kind of a "nobody has asked for this, but it's consistent with onerror" thing

[02:38:39.0000] <annevk>
Does Worker's onerror fire for all exceptions or just during compile?

[02:38:56.0000] <jochen__>
i'd be surprised

[02:39:00.0000] <Domenic>
Good question... bz seemed to imply all errors, but worth checking...

[02:39:13.0000] <annevk>
I do agree that being consistent would be nice

[02:39:21.0000] <jochen__>
if it fired for all exceptions

[02:39:24.0000] <annevk>
And it doesn't seem super hard to post a message across the process...

[02:39:25.0000] <jochen__>
because out of process

[02:39:34.0000] <jochen__>
what would the message contain?

[02:39:37.0000] <Domenic>
Nah, all errors https://html.spec.whatwg.org/multipage/workers.html#runtime-script-errors-2

[02:39:52.0000] <Domenic>
"For dedicated workers, if the error is still not handled afterwards, the user agent must queue a task to fire a trusted event that uses the ErrorEvent interface..."

[02:40:02.0000] <Domenic>
ohhhh interesting

[02:40:10.0000] <Domenic>
"and with the error attribute initialised to null"

[02:40:13.0000] <annevk>
jochen__: sorry, I meant internally the browser would use a message to transmit the error...

[02:40:21.0000] <Domenic>
instead of trying to structured clone the error object or something

[02:40:23.0000] <Domenic>
that is the problem in this case

[02:40:35.0000] <annevk>
there's no structured cloning of Error objects

[02:40:36.0000] <Domenic>
to get a coherent PromiseRejectionEvent you'd have to structured clone the { promise, error } object

[02:40:38.0000] <Domenic>
yeah

[02:40:47.0000] <Domenic>
so we could fire an event with no information...

[02:41:07.0000] <jochen__>
right

[02:42:03.0000] <Domenic>
The best we could do (messy) is switch from promise objects to promise IDs, and then also have a message field (optionally lineno/columno/filename).

[02:42:06.0000] <Domenic>
Seems not worth it

[02:42:19.0000] <annevk>
I think we should fix structured cloning of Error btw: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28389

[02:43:18.0000] <Domenic>
s/of Error// ;)

[02:43:25.0000] <annevk>
maha

[02:43:29.0000] <annevk>
good luck with that

[02:43:30.0000] <jochen__>
there's no guarantee that the reason is a an error

[02:43:35.0000] <jochen__>
could be an array buffer

[02:43:35.0000] <annevk>
But yeah, promises seems harder

[02:43:36.0000] <Domenic>
^ right, also that

[02:43:52.0000] <annevk>
true

[02:44:03.0000] <jochen__>
so: no events on *Worker objects :)

[02:44:26.0000] <Domenic>
We should get bz's buy in on that, but it sounds good to me...

[02:44:27.0000] <jochen__>
also, the event isn't really like the error event

[02:44:28.0000] <annevk>
I mean in the other case we also fire without any information...

[02:44:42.0000] <Domenic>
in the other case we have message/lineno/colno/filename

[02:44:49.0000] <jochen__>
that has a lot of special implications that are just not true for this event, i.e., it's own kind of event listener

[02:45:17.0000] <jochen__>
so what about this phase after microtask checkpoint thing

[02:45:32.0000] <annevk>
Domenic: you can just do null defaulting in the dictionary

[02:46:05.0000] <annevk>
Domenic: since the event cannot be constructed without the dictionary that's fine

[02:46:38.0000] <Domenic>
annevk: this null thing is quite confusing actually

[02:46:52.0000] <Domenic>
annevk: Firefox seems to give undefined for things HTML says are null

[02:47:00.0000] <annevk>
oh

[02:47:24.0000] <Domenic>
HTML is imprecise

[02:47:28.0000] <annevk>
You don't have to use null

[02:47:28.0000] <Domenic>
let me find what i am talking about

[02:47:36.0000] <annevk>
And you could require both a promise and a reason

[02:48:06.0000] <annevk>
not sure what "require any reason" would imply though, I guess best to leave that optional

[02:48:21.0000] <annevk>
(or even better, figure out what that means)

[02:51:07.0000] <jochen__>
Domenic: did you see my new pull requests btw?

[02:51:28.0000] <Domenic>
jochen__: yeah, I've been having fun with V8 extras today, will probably merge when I get home from work

[02:51:37.0000] <Domenic>
annevk: here is an example of null that confuses me. https://html.spec.whatwg.org/multipage/comms.html#messageevent

[02:51:50.0000] <Domenic>
"The data attribute must return the value it was initialised to. When the object is created, this attribute must be initialised to null."

[02:51:59.0000] <Domenic>
But (new MessageEvent({})).data === undefined

[02:52:28.0000] <annevk>
Domenic: that's a bug

[02:52:39.0000] <Domenic>
Maybe because of how the constructor works? But teh constructor isn't specified outside of IDL as far as I can tell.

[02:53:06.0000] <annevk>
We have a generic description for event constructors: https://dom.spec.whatwg.org/#constructing-events

[02:53:21.0000] <annevk>
It needs some cleaning up though to work with internal slots and stuff, but IDL hasn't formalized those :-(

[02:53:26.0000] <Domenic>
Ah OK, that's nifty

[02:53:39.0000] <Domenic>
So that definition implies .data === undefined I think since {}.data === undefined

[02:53:52.0000] <annevk>
But note that if a dictionary member is undefined it's missing so it wouldn't be set by that constructor

[02:53:54.0000] <Domenic>
So I guess... null only matters for UA created MessageEvents that don't bother to set data?

[02:54:02.0000] <Domenic>
Hmm

[02:54:05.0000] <annevk>
So it would be null per the prose rules

[02:54:22.0000] <Domenic>
"for each dictionary member defined therein find the attribute on event whose identifier matches the key of the dictionary member and then set the attribute to the value of that dictionary member" I dunno

[02:54:28.0000] <Domenic>
"data" sounds like a dictionary member defined therein

[02:54:34.0000] <annevk>
But instead of relying on prose it's way better to just default to null in the dictionary for events that can't be created through document.createEvent()

[02:55:11.0000] <Domenic>
OK well defaulting to null seems like a good plan I'll file that on myself and fix later.

[02:55:41.0000] <annevk>
Domenic: I think IDL says that if a member is "undefined" it's not defined

[02:56:15.0000] <Domenic>
I read it as referring to the actual definition, i.e. `dictionary MessageEventInit { ... }`

[02:56:39.0000] <annevk>
Nope, it refers to the argument passed

[02:57:18.0000] <annevk>
But it should use "present" and "not present" as terminology...

[02:57:29.0000] <Domenic>
*shrug*

[02:57:33.0000] <Domenic>
bbiab, food time

[03:07:47.0000] <jochen__>
enjoy

[03:50:42.0000] <JakeA>
wanderview: that bug report on Twitter… Firefox fails a CORS check for fetch('//other-origin/foo') from a page, even if the serviceworker returns a valid non-opaque response

[04:09:05.0000] <annevk>
I wonder why Google Calendar can confirm via email that someone is attending but cannot actually show that information in the event... Maybe a bug specific for organizations using Google Calendar?

[04:41:04.0000] <annevk>
Domenic: it seems weird that Streams makes many states unobservable

[04:41:19.0000] <Domenic>
annevk: streams are supposed to be largely stateless

[04:41:30.0000] <annevk>
Domenic: e.g. not being able to distinguish an empty stream from a non-read canceled stream is just... uh

[04:41:31.0000] <Domenic>
annevk: e.g. consider arrays, you don't care how the array became empty

[04:41:49.0000] <Domenic>
they're a data structure, not a record of what's happened in your system

[04:42:41.0000] <annevk>
Hmm, guess I have to think about it more

[05:06:41.0000] <annevk>
Domenic: why is it a good thing that they don't keep track? Most asynchronous data structures seem to keep track in some way...

[05:07:29.0000] <annevk>
And more specifically I'd think most stream implementations would keep track of such details

[05:25:23.0000] <Domenic>
annevk: no async data structures I can think of keep track. Certainly not promises. No data structures in general, that I can think of. Why? Hmm...

[05:25:53.0000] <annevk>
Domenic: https://w3c.github.io/FileAPI/#dfn-Blob does

[05:26:15.0000] <Domenic>
annevk: no, it definitely doesn't. Example:

[05:26:25.0000] <annevk>
Domenic: isClosed?

[05:26:49.0000] <Domenic>
You can't distinguish between a blob with [1,2,3,4,5] created from scratch, versus a blob with [1,2,3,4,5] created from slicing a blob [1,...,1000]

[05:27:10.0000] <Domenic>
sure, but all closed blobs are the same

[05:27:24.0000] <Domenic>
nobody cares if the closed blob used to have 1000 bytes in it or 0

[05:27:28.0000] <annevk>
but they're distinguishable from empty blobs

[05:27:59.0000] <Domenic>
i mean, empty but not-yet-closed streams are distinguishable from empty-and-closed streams

[05:28:16.0000] <Domenic>
it's just that if you know there's no more data to put in the stream, there's not much point in keeping the stream unclosed.

[05:28:22.0000] <annevk>
I thought wanderview said that was not true

[05:28:31.0000] <Domenic>
just makes it annoying for anyone to figure out whether the stream is over yet

[05:28:33.0000] <Domenic>
same as blobs

[05:29:07.0000] <Domenic>
ehhhh it's borderline, it's a matter of whether .getReader().closed fulfills immediately or not

[05:30:12.0000] <Domenic>
we could add synchronous querying of the fact, but in general it's better to just write generic code that isn't so concerned with the state, and deals with the generic starts-readable-becomes-closed scenario, with starts-readable-immediately-becomes-closed as a special case.

[05:31:19.0000] <annevk>
I guess it's okay, it seems somewhat weird that if you cancel a stream it's suddenly treated as the empty string, but folks will deal

[05:32:17.0000] <Domenic>
remember you can only cancel if you "own" it (i.e. you can get a reader)

[05:36:31.0000] <annevk>
So actually, is that not a problem for the synthetic case we've been discussing?

[05:36:42.0000] <Domenic>
hmm how so?

[05:37:34.0000] <annevk>
You can now empty any response from a server and the browser cannot tell whether the server returned the empty string or someone meddled with the stream

[05:37:53.0000] <Domenic>
@#&*()*$

[05:38:48.0000] <Domenic>
OK. I will think about that tomorrow. That caught me by surprise a lot. Dammit.

[05:41:04.0000] <annevk>
We should just have an isDirty flag, would work instead of offset too... :-P

[05:41:44.0000] <Domenic>
I mean, last time my mind was blown, I went from "no state!!" to "OK I guess offset is not the worst thing ever." Maybe tomorrow I'll come around to isDirty :(

[05:42:06.0000] <Domenic>
I guess a wrapper also would handle all of this

[05:42:50.0000] <annevk>
Would that impact speed? But sure...

[05:42:53.0000] <Domenic>
But yhirano_ worries about performance, especially with piping

[05:42:54.0000] <Domenic>
yeah

[05:43:26.0000] <annevk>
Ideally what we expose here is the lowest of the lowest-level stuff, minus all the security bugs

[05:43:31.0000] <Domenic>
in theory it shouldn't but in the still-somewhat-speculative world of off-main-thread piping, it could. So far that world is pretty vague but we've tried to maintain enough flexibility.

[05:52:51.0000] <Domenic>
You can also do yhirano_'s preferred wrapper https://github.com/yutakahirano/fetch-with-streams/pull/43#issuecomment-110968431 which should not impact perf

[05:52:58.0000] <Domenic>
i should sleep

[07:35:51.0000] <annevk>
jochen__: Domenic: https://bugzilla.mozilla.org/show_bug.cgi?id=1179244

[07:37:13.0000] <jochen__>
"Your password fails to meet the security requirements" blabla

[07:54:06.0000] <smaug____>
annevk: so the promise event stuff will be in DOM or HTML spec?

[07:54:11.0000] <smaug____>
at least the DOM Event part of it?

[07:54:32.0000] <annevk>
it's described as patches to HTML and ECMAScript

[07:56:09.0000] <smaug____>
another question, annevk did you figure out where and when the custom element meeting actually will be?

[07:57:36.0000] <smaug____>
(even if I had stronger opinions on custom elements, the timing is rather bad. July is the holiday month in Finland )

[07:57:41.0000] <annevk>
smaug____: not yet, the ball is with slightlyoff it seems

[07:57:54.0000] <annevk>
smaug____: it's very likely in Mountain View

[07:58:05.0000] <annevk>
smaug____: but it could move to San Francisco I suppose

[07:58:31.0000] <annevk>
I'm staying in San Francisco since that's where the service worker meetup will be, I believe

[07:58:51.0000] <smaug____>
oh, right, that one too

[08:00:08.0000] <smaug____>
waiting to see the time when SW is stable and implemented everywhere

[08:00:35.0000] <smaug____>
maybe next year

[08:30:30.0000] <MikeSmith>
annevk: the custom elements meeting is on July 21st, right? < smaug____

[08:30:58.0000] <annevk>
MikeSmith: yes

[08:31:42.0000] <smaug____>
yes, that one, but still unclear where

[08:32:02.0000] <MikeSmith>
ah ok

[08:33:15.0000] <MikeSmith>
I assumed it will be at Google in Mountain View where we had it last

[08:33:29.0000] <MikeSmith>
*where we had the Shadow DOM meeting

[08:33:45.0000] <MikeSmith>
but that room was too small

[08:33:51.0000] <MikeSmith>
and not arranged so well

[08:34:19.0000] <MikeSmith>
or I dunno, maybe that actually helped the meeting be more productive

[08:49:24.0000] <annevk>
I hope there's not going to be a ton of people...

[08:52:46.0000] <JoWie>
no holographic telepresence at google yet?

[09:23:24.0000] <smaug____>
annevk: MikeSmith: one thing which made the last meeting a bit hard was the proposals coming right before the meeting

[09:23:47.0000] <smaug____>
getting proposals a week earlier or so would have perhaps made the meeting even more productive

[09:24:35.0000] <annevk>
smaug____: agreed

[09:25:07.0000] <annevk>
I've been trying to do my homework https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors but so far that has made me skeptical of doing Custom Elements at all...

[09:29:49.0000] <smaug____>
annevk: btw, I think cloning for printing isn't  perhaps that interesting case, since we wouldn't probably run ctors, but try to clone whatever there is in shadow DOM or so, I think

[09:29:53.0000] <smaug____>
not sure  though

[09:30:02.0000] <smaug____>
in Gecko we don't run scripts in the clone document

[09:30:47.0000] <smaug____>
beforeprint may change the original document right before printing and then afterprint restore the state after cloning

[09:30:51.0000] <smaug____>
as of now

[09:31:06.0000] <annevk>
smaug____: if in order to create an element you need to run its constructor, cloning would need to do that too

[09:32:27.0000] <smaug____>
not sure about clone-for-printing

[09:32:32.0000] <smaug____>
that is rather odd case

[09:32:42.0000] <annevk>
bz likes to bring it up

[09:32:52.0000] <annevk>
but same goes for text selection and then copying things

[09:32:56.0000] <smaug____>
it just needs some state which can be printed

[09:33:10.0000] <annevk>
sure

[09:33:32.0000] <smaug____>
selection is perhaps more valid case, and just plain normal cloneNode()

[09:34:20.0000] <annevk>
cloneNode() invoking some JavaScript seems harmless

[09:34:45.0000] <annevk>
the parser invoking JavaScript is potentially problematic, since non-</script> points are not vetted

[09:35:12.0000] <annevk>
and then there's various algorithms in browsers that want to clone elements, such as printing and editing, that might not anticipate the world to change

[09:36:52.0000] <smaug____>
cloneNode(true): when should the ctors run?

[09:42:36.0000] <annevk>
smaug____: prolly in tree order

[09:43:01.0000] <annevk>
philipj: richt: davve: is the plan to support Web Audio without <audio> / <video> indirection?

[09:45:23.0000] <smaug____>
annevk: but during cloning or right after?

[09:45:52.0000] <richt>
annevk: yes.

[09:45:57.0000] <annevk>
smaug____: during, but I see how that would be problematic

[09:46:20.0000] <annevk>
richt: hey, I have some other questions I'd like to ask

[09:46:26.0000] <annevk>
mostly relaying from sicking

[09:46:47.0000] <annevk>
richt: can "content" playback tell apart the user pressing pause and transient-solo happening?

[09:47:09.0000] <richt>
annevk: not currently, no.

[09:47:35.0000] <richt>
annevk: deliberately so that "content" playback respects the transient-solo interruption.

[09:47:36.0000] <annevk>
richt: e.g. if the user presses pause we'd like for the app to indicate in its controls that the user can resume

[09:47:48.0000] <annevk>
richt: but with transient-solo the app would want to disable its own controls

[09:48:46.0000] <annevk>
richt: it seems we have to enforce that interruption at a higher level either way

[09:50:45.0000] <annevk>
richt: I filed https://github.com/whatwg/mediasession/issues/89 to track this

[09:51:55.0000] <richt>
annevk: it's a good question. let's discuss further on gh.

[12:08:30.0000] <wanderview>
JakeA: annevk: sanity check me please... a service worker script itself (an its importScripts()) should not be able to be intercepted, right?

[12:12:14.0000] <JakeA>
wanderview: correct, they shouldn't

[12:12:31.0000] <wanderview>
JakeA: I'm glad you survived your train ride

[12:13:05.0000] <wanderview>
and thanks

[12:18:18.0000] <JakeA>
I only just survived. I'm all out of sweat that's for sure.

[14:17:42.0000] <Krinkle>
JakeA: Is there a way to inspect CacheStorage/window.caches visually in Chrome? (akin to the other Resources)

[14:23:40.0000] <JakeA>
Krinkle: yes, in the resources tab

[14:24:04.0000] <Krinkle>
Hm.. perhaps under a few layers of experimental options?

[14:24:10.0000] <JakeA>
Krinkle: might only be in beta/Canary

[14:24:10.0000] <Krinkle>
/me tries Chromium instead of canary

[14:24:18.0000] <Krinkle>
Canary is my defualt

[14:24:36.0000] <JakeA>
Krinkle: but yeah, enable the devtools experiments flag

[14:25:31.0000] <Krinkle>
Ha, got it.

[14:25:43.0000] <Krinkle>
I had one random window open in Chrome stable

[14:25:47.0000] <Krinkle>
the one I happened to be using the console of

[14:25:48.0000] <Krinkle>
:)

[14:26:08.0000] <Krinkle>
Yeah,it's there in canary. great.

[14:30:05.0000] <Krinkle>
JakeA: You mentioned there were security concerns about exposing caches on window. You reckon that may realistically result in it being withdrawn?

[14:30:26.0000] <Krinkle>
I'm seeing a benefit in being able to populate caches on the first hit when SW isn't active yet.

[14:35:13.0000] <JakeA>
Krinkle: I think it'll stay. Worst comes to the worst, you can postmessage to your installing worker telling it to cache some stuff

[14:35:52.0000] <Krinkle>
JakeA: Yeah.

[14:45:40.0000] <Krinkle>
While somewhat "uncool", we're also looking into trying without SW. Just being honest.

[14:45:51.0000] <Krinkle>
We don't need the 'fetch' event from SW as requests go via our loader function. SW also means we have to re-create large parts of the loader function to know which requests to ignore.

[14:46:00.0000] <Krinkle>
From window we can populate and access cache. This does necessitate indirect eval, but localStorage does that already now :-/

[14:46:19.0000] <Krinkle>
Without SW, it won't work offline. But, working offline won't work anyway until other infrastructure adapts. Getting SW right as the first puzzle piece for offline would be cool, but we're looking to get big performance gains first. Offline is not our team's objective :(

[15:07:15.0000] <smaug____>
zcorpan: so resize event

[15:07:28.0000] <smaug____>
I couldn't land the patch implementing the behavior the spec has

[15:07:37.0000] <smaug____>
since it regresses performance

[15:08:03.0000] <smaug____>
this is the generic issue that too much stuff is happening around animation frame tick

[15:09:24.0000] <smaug____>
if an event listener takes much time, updating the graphics may be postponed too much

[15:11:30.0000] <zcorpan>
smaug____: ywah?

[15:13:16.0000] <zcorpan>
smaug____: ok. the relative order of things is in the html spec, so file a bug for hixie

[15:14:23.0000] <smaug____>
zcorpan: the issue is that I don't really have any good proposal how resize handling should be spec'ed

[15:14:55.0000] <zcorpan>
smaug____: file a bug anyway describing the problem :-)

[15:15:55.0000] <smaug____>
/me files

[15:16:37.0000] <smaug____>
I think I filed a separate, but related bug to have a way to say a callback should be called after animation frame tick

[15:20:18.0000] <zcorpan>
i need to sleep now. will be offline for some more weeks

[15:21:04.0000] <zcorpan>
file bugs or send me email for anything i should look at later :-)

[15:25:59.0000] <smaug____>
he left, but https://www.w3.org/Bugs/Public/show_bug.cgi?id=28876


2015-07-02
[19:10:49.0000] <Domenic>
penguin-breeder.org, really jochen__??

[19:11:10.0000] <Domenic>
... huh ok it's a real thing

[19:11:30.0000] <Domenic>
(I was surprised that your email in bugzilla was at a ... strange ... domain name)

[20:41:07.0000] <Domenic>
annevk: yeah... I am also feeling discouraged about custom elements now...

[21:36:32.0000] <Domenic>
This site-wide heading thread is a bit sad

[21:36:37.0000] <Domenic>
I thought those usually ended up on public-html

[23:52:23.0000] <annevk>
philipj: Fullscreen: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27865 does this proposal seem reasonable to you?

[23:52:40.0000] <annevk>
philipj: xidorn is asking me to fix that to unblock unprefixing efforts in Gecko

[00:42:37.0000] <howdoi>
say we have promise, which has a timeout in it, if we reject the promise,  the timeout will not get rejected, which is the best way to handle this?

[00:42:40.0000] <howdoi>
Domenic's new proposal solves this?

[01:25:43.0000] <annevk>
howdoi: wrap the rejection?

[01:25:51.0000] <annevk>
howdoi: so that you can also cancel the timeout?

[01:26:07.0000] <howdoi>
well, something like canellable promise

[01:26:08.0000] <howdoi>
?

[01:26:23.0000] <annevk>
howdoi: I don't see why that would handle timeouts automatically

[01:27:17.0000] <howdoi>
hmm

[01:27:41.0000] <howdoi>
it won't, but on cancelation clearing timeout will be done

[01:35:58.0000] <annevk>
JakeA: https://github.com/slightlyoff/ServiceWorker/issues/718

[01:36:20.0000] <annevk>
JakeA: might have helped if some design input from Mozilla was taken

[01:37:40.0000] <JakeA>
annevk: still believe that SW without fetch is a rarity. Question is how much we should bend over backwards for the math.random case

[02:02:34.0000] <philipj>
annevk: are you there? I'm a bit confused about something you took from https://github.com/inexorabletash/polyfill/commit/a9f17a7bacc588de674832b47241e22ebf40a676

[02:02:55.0000] <annevk>
philipj: okay

[02:03:12.0000] <philipj>
in the https://dom.spec.whatwg.org/#dom-childnode-replacewith steps, how can the parent change between step 1 and 5?

[02:03:14.0000] <annevk>
JakeA: it's not exactly bending over backward to make it opt-in

[02:03:24.0000] <annevk>
JakeA: just like every other service worker feature is

[02:03:45.0000] <JoWie>
bluebird had cancellable promises

[02:03:55.0000] <philipj>
annevk: Paritosh says something about mutation events, but the steps in between don't seem to do anything that could fire mutation events

[02:04:04.0000] <annevk>
philipj: if parent is in nodes

[02:04:42.0000] <annevk>
oh wait

[02:04:43.0000] <annevk>
no

[02:05:12.0000] <philipj>
oh right, the convert step appends to a fragment, but does can that fire an event on any node you already had a reference to?

[02:05:13.0000] <annevk>
philipj: context object might have been inserted into the DocumentFragment

[02:05:25.0000] <philipj>
annevk: oh, right

[02:05:40.0000] <annevk>
this is not taking into account mutation events

[02:05:45.0000] <annevk>
mutation events are dead to the DOM spec

[02:05:52.0000] <annevk>
an assumption we might have to revisit at some point I guess

[02:05:59.0000] <philipj>
annevk: ok, can you maybe add a note in the spec for this not-so-obvious check?

[02:06:32.0000] <philipj>
I can file an issue if this is not a good time

[02:06:50.0000] <annevk>
"Note: context object might have been inserted into /node/."?

[02:07:14.0000] <philipj>
annevk: yeah, sounds good

[02:07:32.0000] <philipj>
s/might/may/ I guess, but I'm no jgraham

[02:07:48.0000] <annevk>
I'll make it could

[02:07:50.0000] <annevk>
may is normative

[02:08:09.0000] <philipj>
oh right

[02:09:51.0000] <JoWie>
i could imagine synchronous mutation observation would be very useful for custom elements

[02:11:28.0000] <annevk>
Hmm, DOM is hitting bikeshed errors again

[02:11:52.0000] <annevk>
FATAL ERROR: No 'argument' refs found for 'title'.

[02:11:57.0000] <annevk>
FATAL ERROR: No 'argument' refs found for 'deep' with for='Node/cloneNode(deep)'.

[02:12:17.0000] <annevk>
I "fixed" the second one, though it seems like a bug in bikeshed, not sure about the first

[02:19:31.0000] <howdoi>
When can we expect streams in the browser ?

[02:19:44.0000] <howdoi>
Domenic has a proposal from a very long time, right?

[02:20:43.0000] <Domenic>
howdoi: they're shipping in Chrome 43+

[02:20:52.0000] <Domenic>
and Mozilla announced they will be working on it

[02:21:03.0000] <annevk>
TabAtkins: I need your help

[02:21:12.0000] <howdoi>
wow! \o/ that's some good news! Thanks Domenic

[02:21:13.0000] <annevk>
TabAtkins: something seems screwy around optional arguments

[02:22:42.0000] <annevk>
philipj: tracked adding a note in https://github.com/whatwg/dom/issues/48

[02:22:48.0000] <philipj>
annevk: thanks!

[02:27:49.0000] <howdoi>
Domenic: I'm on Version 43.0.2357.130, can I check streams out in canary?

[02:29:01.0000] <Domenic>
howdoi: no need for canary, but it will work there too. See https://googlechrome.github.io/samples/fetch-api/fetch-response-stream.html for a sample.

[02:38:47.0000] <howdoi>
res.body.getReader()

[03:01:45.0000] <howdoi>
was looking for readableStream.pipeTo(writableStream)

[04:10:35.0000] <annevk>
davve: I wonder how you end up with 40l30 as path values there

[04:10:49.0000] <annevk>
davve: would have assumed three set of coordinates in the range 0-100

[04:10:52.0000] <annevk>
davve: for a triangle

[04:11:39.0000] <annevk>
I'm probably way too nitpicky about these logos though

[04:13:17.0000] <davve>
annevk: :) I'll try to grab the design savvy guy around before I optimize it too far.

[04:13:43.0000] <annevk>
Oh wait, now I paste it here I see that 1 is actually an l

[04:13:45.0000] <annevk>
fonts...

[04:14:36.0000] <annevk>
Though still a couple coordinates too many

[04:28:26.0000] <annevk>
philipj: if we give elements a "fullscreen flag", would that not be enough to merge the two stacks?

[04:38:24.0000] <philipj>
annevk: probably, I'm just wondering if the existing constraints should stay or not

[04:39:46.0000] <philipj>
making it exactly as forgiving as the top layer rules sounds good to me, unless iframes make that somehow complicated

[04:40:14.0000] <annevk>
philipj: in #content, Mozilla, xidorn is suggesting we just invent a new value for z-index, "topmost" or some such, and drop ::backdrop for fullscreen...

[04:40:46.0000] <annevk>
philipj: xidorn will email the WHATWG list with that proposal

[04:50:06.0000] <philipj>
annevk: I don't see the connection between those things, the backdrop is to make the background black is it not?

[04:54:47.0000] <annevk>
philipj: well you could style ::backdrop in any number of ways

[04:55:17.0000] <annevk>
philipj: apparently Chrome and Gecko currently abuse z-index to implement the top layer

[04:55:30.0000] <annevk>
philipj: so there's not actually a top layer thing, except for <dialog> in Chrome

[04:56:56.0000] <annevk>
Domenic: I was thinking a bit about the day when IDL is more formalized

[04:57:16.0000] <annevk>
Domenic: presumably for IDL-defined methods it would have to invoke some kind of algorithm with a predictable name

[04:58:56.0000] <annevk>
Domenic: so you'd get something like the IDL specification "generating text" that ends up invoking NodeBaseURIGetter(this) for interface Node { readonly attribute DOMString baseURI };

[04:59:34.0000] <annevk>
Domenic: or maybe @NodeBaseURIGetter(this) since we'd want it to be internal

[05:00:04.0000] <annevk>
heycam|away: ^^

[05:00:47.0000] <annevk>
I think that's roughly where we want to go. It would also make specifications a lot more predictable in how they are structured and such...

[05:06:05.0000] <annevk>
Domenic: so anyway, establishing some conventions for all this stuff would be great

[05:07:07.0000] <annevk>
Domenic: also, if we do this we'd no longer have the problem of people just invoking methods that could be prototyped over by JavaScript, since they'd just refer to the internal algorithms directly

[05:07:29.0000] <annevk>
Domenic: which incidentally matches what implementations are doing, so makes that clearer too

[05:07:32.0000] <annevk>
Domenic: so many wins

[05:10:48.0000] <Domenic>
annevk: hmm, I'd always thought we'd handle that by saying Node instances have a [[baseURI]] internal slot, and baseURI returns that

[05:11:00.0000] <Domenic>
Then specs would say that they look at node@[[baseURI]]

[05:17:50.0000] <philipj>
annevk: correct, moving Fullscreen to the top layer in Blink is blocking shipping in Blink too

[05:58:58.0000] <annevk>
Domenic: so that's the default algorithm for such a thing

[05:59:57.0000] <annevk>
Domenic: so IDL would probably say if "<var>Class</var><var>Property</var>PropertyGetter" is defined, invoke that, otherwise, return <var>Class</var>@[[<var>Property</var>]].

[06:00:15.0000] <annevk>
Domenic: because we have more complicated getters, setters, and method definitions that IDL can't predict

[06:02:32.0000] <annevk>
I guess I might be alone in finding that all somewhat nice...

[06:02:53.0000] <annevk>
But it's been kind of a nuisance to me that the interaction between IDL and the rest of the platform is handwavy

[06:17:40.0000] <annevk>
philipj: so discard what I said earlier about xidorn; he discovered IE is already shipping this so we'll go ahead

[06:17:59.0000] <annevk>
philipj: I'll make a pass through the spec replacing stack checks with top layer + fullscreen flag checks

[06:18:26.0000] <annevk>
philipj: I'm a bit sad how much synchronous layout this is, but I guess we had that already anyway

[06:40:08.0000] <philipj>
annevk: what do you mean? adding and removing things to the top layer doesn't require sync layout does it?

[06:40:16.0000] <philipj>
it invalidates the layout, sure

[06:40:39.0000] <philipj>
it seems as long as the spec never says getBoundingClientRect() or some such there shouldn't be a problem?

[06:41:36.0000] <annevk>
philipj: I guess it depends on where the top layer is

[06:41:39.0000] <annevk>
philipj: fair

[06:42:14.0000] <philipj>
annevk: if xidorn says it requires looking at the layout tree in Gecko I'm sure that's correct, it would just be very surprising to me

[06:42:41.0000] <annevk>
I haven't been talking to xidorn about this, was just considering top layer a layout thing myself

[06:43:40.0000] <annevk>
Which is probably wrong

[07:12:29.0000] <JakeA>
Domenic: https://github.com/domenic/cancelable-promise/issues/2

[09:20:49.0000] <wanderview>
JakeA: if I do a cache.addAll(urlList) and one of the url's results in a 404... what do you think cache should do?

[09:21:06.0000] <wanderview>
the spec seems to say it should stick the 404 in the cache

[09:21:28.0000] <wanderview>
is that expected?

[09:21:30.0000] <JakeA>
wanderview: yes, else it becomes a mechanism to detect 404s on other origins

[09:22:11.0000] <wanderview>
JakeA: so evt.waitUntil(cache.addAll(urls)) is not really adequate for installing an app then?

[09:22:30.0000] <wanderview>
since you might not have actually gotten all of them installed if one hit a 503 or something

[09:23:19.0000] <JakeA>
wanderview: I agree it's tricky, but you may want to cache a 404 to present to the user while offline

[09:23:35.0000] <JakeA>
wanderview: I'd have liked it to fail on 404, but security says no (lemmie dig up the ticket)

[09:23:50.0000] <wanderview>
JakeA: ok... I'm willing to accept it... the WPT test case that verifies success for a non-existent resource just looked weird to me

[09:24:42.0000] <annevk>
wanderview: I recommend reading the topic :p

[09:25:11.0000] <wanderview>
JakeA: seems like just always accepting opaque responses and checking status code for other types might be safe?

[09:25:17.0000] <wanderview>
but whatever

[09:25:43.0000] <JakeA>
wanderview: I've been thinking about an option to add/addAll that would reject on 404 or any opaque response

[09:26:15.0000] <annevk>
please make it reject on any non-2xx response in that case

[09:26:27.0000] <annevk>
that would at least somewhat be founded in primitives

[09:26:35.0000] <annevk>
or make it an option of sorts

[09:26:47.0000] <JakeA>
agreed

[09:26:58.0000] <JakeA>
in fact, wanderview, here's me & you talking about it https://github.com/slightlyoff/ServiceWorker/issues/407#issuecomment-92341768

[09:27:08.0000] <JakeA>
annevk: looks like it uses response.ok

[09:27:29.0000] <annevk>
seems alright

[09:28:19.0000] <annevk>
ah yeah, as I was saying there it should be an option for request, but I guess addAll could overwrite requests...

[09:28:56.0000] <wanderview>
annevk: if we hit a cached resource, do we not get a 304?

[09:29:16.0000] <wanderview>
or is that supposed to be silently converted to 200 using the cached value

[09:29:22.0000] <JakeA>
wanderview: fetch handles that internally and returns the cached resource

[09:29:28.0000] <wanderview>
right, ok

[09:29:38.0000] <annevk>
(unless you have some specific settings)

[09:29:45.0000] <wanderview>
JakeA: it seems my response on that thread is pretty close to me current "but whatever"

[09:30:02.0000] <wanderview>
I agree its a bit weird for devs, though

[09:33:09.0000] <JakeA>
wanderview: yeah, I tried to get the appcache behaviour through, but I think that was seen as a security error that they want to undo

[09:34:33.0000] <wanderview>
JakeA: annevk: btw, I ran into something in chrome that I was curious if it was spec'd or unique to implementation... I tried to do intercept https://foo.com with http://bar.com and chrome gave me a mixed content warning (should be blocked anyway for opaque navigation)

[09:34:40.0000] <wanderview>
was just curious about the mixed content thing, though

[09:35:40.0000] <annevk>
wanderview: I think that's because the SW fetched mixed content

[09:35:49.0000] <annevk>
wanderview: we should do that too

[09:35:51.0000] <wanderview>
annevk: but I don't see where that is blocked in the fetch

[09:35:54.0000] <JakeA>
annevk: shouldn't it just be blocked?

[09:35:56.0000] <wanderview>
blocked in the spec

[09:36:09.0000] <annevk>
well before it's blocked it's mixed content

[09:36:27.0000] <wanderview>
annevk: I mean... if it does a cors request to a http... it should work

[09:36:28.0000] <JakeA>
annevk: I thought the request would be blocked, so no mixed content happens

[09:36:38.0000] <annevk>
why would the request be blocked?

[09:36:53.0000] <JakeA>
Because it's an http request from an https environment

[09:36:57.0000] <annevk>
in https://fetch.spec.whatwg.org/#http-fetch step 2.2 a network error is returned for that response

[09:37:12.0000] <annevk>
JakeA: we allow that because of your podcast thing

[09:37:34.0000] <wanderview>
annevk: thats just for an opaque response, right?  if I do a cors mode request to untrusted, it should work right?

[09:37:49.0000] <annevk>
wanderview: 'request is a client request and response's type is neither "basic" nor "default". '

[09:38:15.0000] <annevk>
wanderview: oh CORS

[09:38:24.0000] <annevk>
wanderview: that is blocked due to mixed content

[09:38:43.0000] <annevk>
wanderview: in step 4 of https://fetch.spec.whatwg.org/#concept-main-fetch

[09:38:47.0000] <JakeA>
ahh ok, so no-cors requests are let through?

[09:38:53.0000] <annevk>
yes, because of you

[09:38:59.0000] <annevk>
I was kind of hoping we would block those too...

[09:39:14.0000] <annevk>
(and I guess because it would make upgrading existing sites to use SW even harder)

[09:39:20.0000] <wanderview>
annevk: thanks

[09:39:24.0000] <annevk>
(but now we're there I'm not quite sure it was worth it)

[09:40:17.0000] <annevk>
That you don't even remember how that went down suggests we should maybe reconsider that decision, since it was somewhat controversial at least with some people...

[09:40:33.0000] <JakeA>
I do remember

[09:43:10.0000] <JakeA>
Being able to make a mixed request without a window to show the warning in feels wrong though

[09:43:14.0000] <annevk>
JakeA: sorry, didn't mean for this exchange to happen this way

[09:43:36.0000] <annevk>
JakeA: yeah, I think we are disallowing that

[09:43:52.0000] <annevk>
JakeA: although we haven't specified it yet

[09:44:42.0000] <JakeA>
annevk: this is making me think of event.client.fetch() again

[09:45:01.0000] <annevk>
JakeA: I'm just gonna hide in a corner now

[09:45:05.0000] <JakeA>
haha

[09:45:38.0000] <annevk>
JakeA: I do actually have to go, it seems like you're in the better set of timezones again so we can discuss it tomorrow

[09:46:04.0000] <JakeA>
annevk: yeah, I'm in UK, will be in the office early tomorrow

[12:37:44.0000] <Ms2ger>
Anyone have an explanation of why Postel's Law is a disaster handy?

[12:42:18.0000] <MikeSmith>
Ms2ger: http://cacm.acm.org/magazines/2011/8/114933-the-robustness-principle-reconsidered/fulltext sees sane

[12:58:28.0000] <Ms2ger>
ekr already pointed at http://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/

[13:09:53.0000] <MikeSmith>
/me looks

[13:10:15.0000] <MikeSmith>
wow

[13:10:16.0000] <MikeSmith>
nice

[13:10:23.0000] <MikeSmith>
Martin Thomson

[14:10:08.0000] <TabAtkins>
annevk: I'll look into the Bikeshed errors.  Erroring on arguments is *very likely* a Bikeshed bug.  On vacation now and gonna head to friends' soon, but I'll get it by tomorrow.

[16:43:25.0000] <Mateon1>
I was thinking a bit about the await and async keywords. Can you use them on getters and setters? What if you await a function that doesn't return a promise/thenable (is synchronous)?


2015-07-03
[17:40:16.0000] <frewsxcv>
can someone help me understand step 5 here? https://dom.spec.whatwg.org/#dom-childnode-before

[17:40:33.0000] <frewsxcv>
mainly, "and to parent’s first child otherwise"

[17:50:32.0000] <frewsxcv>
basically, what am i setting to parent's first child?

[18:05:08.0000] <Mateon1>
frewsxcv: You set `viablePreviousSibling = (viablePreviousSibling != null ? viablePreviousSibling.nextSibling : parent.firstChild)`, from my understanding

[18:06:16.0000] <Mateon1>
Maybe set node to what I said

[18:06:40.0000] <Mateon1>
I don't think so, though.

[18:12:13.0000] <frewsxcv>
I read "If viablePreviousSibling is non-null, set it to viablePreviousSibling’s next sibling"

[18:12:29.0000] <frewsxcv>
viablePreviousSibling.next_sibling = viablePreviousSibling

[18:12:48.0000] <frewsxcv>
but yours makes more sense

[18:13:01.0000] <frewsxcv>
since mine is basically a recursive assignment

[18:14:27.0000] <frewsxcv>
i suppose my thinking would have been worded "set it as"

[18:20:30.0000] <Domenic>
JakeA: for podcasts, is the iTunes store not HTTPS yet?

[22:01:23.0000] <JakeA>
Domenic: not sure about iTunes, but when we last checked feeds, very little https

[22:40:24.0000] <Domenic>
JakeA: hmm I kind of thought feeds were all hosted by iTunes these days but now I am doubting myself, maybe iTunes is just a directory.

[23:11:22.0000] <JakeA>
Domenic: since you're awake, I've made some decent progress on cancelable promises. The remaining sticking point is propagating cancellation through resolved values

[23:12:08.0000] <JakeA>
Domenic: oh, you replied on github, I should read that first

[23:30:27.0000] <Domenic>
JakeA: not too much substance in my reply really.

[23:30:47.0000] <Domenic>
JakeA: feel free to open more issues or prod me more. Was excited to look at the commit logs.

[23:38:16.0000] <JakeA>
Domenic: I'm on leave next week, so will write up remaining issues. Cheers!

[23:38:29.0000] <Domenic>
bah, you europeans and your vacationing

[23:38:46.0000] <Domenic>
meanwhile I end up in Japan during 4th of July so I miss those two days off

[00:05:17.0000] <annevk>
JakeA: so... did you discuss network-spawned dialogs with sleevi?

[00:07:36.0000] <annevk>
https://github.com/whatwg/dom/issues/49 spam?

[00:07:42.0000] <JakeA>
annevk: I chatted to him mostly about aborting, but he's in the UK today so we might be able to rope him in if he isn't busy with other stuff.

[00:09:19.0000] <annevk>
It seemed to me that his concerns around that were about dialogs mostly, but I might be mistaken

[00:10:22.0000] <JakeA>
annevk: he was also worried about aborting, because we had a security issue around that recently, but it's been patched

[00:11:00.0000] <JakeA>
(will post a ticket for that if I can find it and it's public)

[00:11:54.0000] <JakeA>
annevk: as for dialogs, he just wants to know where to surface http auth etc if the request comes from a SW

[00:14:32.0000] <annevk>
JakeA: if it's not public, can you copy me? Might be helpful guidance in our vetting work

[00:14:50.0000] <annevk>
JakeA: right, so you know fetch() disables HTTP auth?

[00:15:49.0000] <JakeA>
annevk: I didn't. Didn't XHR allow it?

[00:16:28.0000] <annevk>
JakeA: sure, but XHR did lots of silly things, we wanted to make a better XHR, one of the things includes not showing UI by the browser

[00:17:16.0000] <annevk>
(and XHR is a bit more complicated than just allow, e.g. cross-origin or with supplied credentials it would not)

[00:19:04.0000] <JakeA>
annevk: I'm guessing there's nothing in a request object that can change that?  So a SW that does event.respondWith(fetch(event.request)) would break

[00:19:17.0000] <annevk>
right

[00:19:31.0000] <annevk>
It also breaks referrer at the moment, and maybe some other things

[00:19:43.0000] <annevk>
And redirects as we established

[00:21:44.0000] <annevk>
A thing that's not addressed currently is TLS client auth

[00:22:28.0000] <annevk>
Which I think ideally would also not show UI, but according to sleevi that might break some use cases. However, I wonder if we can provide a programmatic API perhaps it might be okay...

[00:23:53.0000] <JakeA>
annevk: sorry for slow replies, train is crawling slowly towards London through various connectivity black holes

[00:24:19.0000] <JakeA>
annevk: is the UI case where the browser asks the user to select a cert?

[00:24:26.0000] <annevk>
Ah okay, I can do something else for a bit first

[00:24:30.0000] <annevk>
Yes

[00:24:49.0000] <annevk>
I think that's basically it, I don't fully understand the protocol involved I'm afraid or where it is defined

[00:27:07.0000] <JakeA>
annevk: I'll see what I can dig up and report back in 30 mins. I'd like to check we're doing the right thing with HTTP auth. It could just be that more of a case for event.default

[00:31:26.0000] <annevk>
Note that what made event.default() notoriously hard was the idea of it handing back something to the service worker. Which makes it serve two clients at once.

[01:02:51.0000] <annevk>
JakeA: what prompted the client.fetch() idea?

[01:02:58.0000] <annevk>
JakeA: and what does it mean?

[01:03:49.0000] <JakeA>
annevk: I was thinking of how a request could be associated with a window client, so there was a place to show any required UI

[01:04:06.0000] <JakeA>
and if there was no associated window client, and a UI was required, the request would fail

[01:04:49.0000] <JakeA>
so event.client.fetch(event.request) could show cert or http auth UI in the client, if the client was a window

[01:05:34.0000] <JakeA>
It'd be easier if the client was part of the request, but that's tricky when it comes to caching

[01:06:18.0000] <annevk>
This seems tricky because it's not clear who is initiating the fetch and what it means in terms of referrer etc.

[01:07:55.0000] <annevk>
Hmm

[01:08:20.0000] <JakeA>
annevk: isn't referrer set when the request is constructed?

[01:08:46.0000] <JakeA>
ahh ok, that happens later

[01:09:05.0000] <annevk>
JakeA: also, request is constructed when fetch() is invoked

[01:09:26.0000] <annevk>
JakeA: referrer is one of the things that's not maintained at the moment

[01:09:57.0000] <annevk>
JakeA: we'd basically have to allow referrer to be set to any same-origin URL and nobody has okayed that idea yet that I know

[01:11:42.0000] <annevk>
(Presumably because nobody else has been thinking about referrer in the context of service workers...)

[01:13:16.0000] <JakeA>
annevk: if an element makes a request for an image, a request is made with the css url as referrer. Is that not reflected in event.request?

[01:14:04.0000] <annevk>
JakeA: I can't quite parse that statement

[01:14:23.0000] <JakeA>
yeah that was bad, let me try again

[01:14:38.0000] <annevk>
JakeA: but, event.request does reflect the referrer, it is however not passed on to fetch() in anyway, fetch() uses the referrer from the environment

[01:15:01.0000] <annevk>
any way*?

[01:16:59.0000] <JakeA>
annevk: ahh ok, so could we allow fetch to use the request's referrer, but put restrictions on when referrer can be set in manually constructed requests?

[01:21:46.0000] <annevk>
JakeA: my idea was that we'd allow referrer to be set to any same-origin URL

[01:22:34.0000] <annevk>
JakeA: if you can take referrer from a Request object you can basically get any same-origin URL anyway

[01:26:46.0000] <JakeA>
annevk: I guess there isn't the concept of a request having headers but you can't see them with JS?

[01:27:52.0000] <annevk>
JakeA: I think all forbidden headers are set post-service-workers in the network layer

[01:28:43.0000] <annevk>
JakeA: what are you thinking of?

[01:32:55.0000] <JakeA>
annevk: "if you can take referrer from a Request object you can basically get any same-origin URL anyway" - so if my page's CSS, on another origin, makes a request for a background image, I can't see the referrer?

[01:33:52.0000] <annevk>
JakeA: s/see/set/?

[01:34:13.0000] <JakeA>
annevk: see, as in event.request in the SW

[01:35:11.0000] <JakeA>
if I intercept the request for my CSS

[01:35:17.0000] <JakeA>
I should just test it…

[01:35:19.0000] <annevk>
Cross-origin CSS seems like a major security hole...

[01:35:43.0000] <annevk>
If A embeds cross-origin CSS B, it should not be able to tell what B is fetching...

[01:35:58.0000] <annevk>
That violates the same-origin policy...

[01:36:07.0000] <annevk>
Did we really not think of this?

[01:36:18.0000] <JakeA>
annevk: you can get that information from computed styles

[01:36:28.0000] <annevk>
That is not at all the same

[01:36:34.0000] <annevk>
Not by a long shot

[01:37:06.0000] <JakeA>
no?

[01:37:06.0000] <annevk>
There's a reason cross-origin CSSOM requires CORS

[01:37:13.0000] <annevk>
No

[01:37:48.0000] <JakeA>
annevk: what does it expose?

[01:38:32.0000] <annevk>
E.g. if that stylesheet uses credentials or relies on firewall IP-based authentication it could expose tokens in images it fetches

[01:39:02.0000] <JakeA>
annevk: that wouldn't show up in computed styles?

[01:39:25.0000] <annevk>
With getComputedStyle you need to know where to look

[01:39:59.0000] <annevk>
And getComputedStyle wouldn't e.g. work with tokens in CSS subresources

[01:40:26.0000] <JakeA>
annevk: by subresources you mean @import?

[01:40:36.0000] <annevk>
Yeah

[01:41:45.0000] <JakeA>
/me goes to check what resource timing API does here

[01:43:49.0000] <annevk>
Not sure that group has done their vetting carefully

[01:44:02.0000] <Ms2ger>
Hah

[01:45:41.0000] <annevk>
TabAtkins: thanks, seems like it's breaking a great number of specifications, e.g. can't update Notifications API either

[01:48:34.0000] <JakeA>
annevk: so resource timing does expose requests from cross-origin CSS

[01:48:44.0000] <annevk>
o_O

[01:49:14.0000] <JakeA>
lemmie check it's not just Chrome…

[01:50:19.0000] <JakeA>
yeah, Firefox exposes it too

[01:50:45.0000] <JakeA>
http://jakearchibald.com/ & performance.getEntriesByType('resource').map(obj => obj.name)

[01:50:58.0000] <annevk>
https://github.com/slightlyoff/ServiceWorker/issues/719

[01:55:07.0000] <annevk>
JakeA: so FWIW, if we can't go the API route for TLS client auth we need something like passing a reference to a client to fetch()

[01:55:49.0000] <annevk>
JakeA: perhaps each worker (including service workers) should simply hold a reference to the "prominent browsing context" (or null) and pass that along

[01:57:27.0000] <annevk>
JakeA: and I guess if we do that, we'd solve the "no-cors" http thing by banning http URLs if that's null (and global's origin is secure, to not affect dedicated/shared workers)

[01:58:28.0000] <JakeA>
annevk: just before we move on from the CSS thing… the CSS make the request (bg img, @import) in the context of the page (it isn't its own client), so isn't it reasonable for that to be visible to the page owner? What about a cross-origin script doing new Image(url)?

[01:58:48.0000] <annevk>
JakeA: and perhaps that check should be in mixed content even, but I'll file an issue against Fetch for now, depending on that HTTP auth issue

[02:01:08.0000] <annevk>
JakeA: a cross-origin script cannot be sure that the things it invokes have not been meddled with

[02:05:12.0000] <JakeA>
Ouch, pretty bad Chrome bug http://musalbas.github.io/address-spoofing-poc/

[02:08:17.0000] <JakeA>
actually you can't interact with the page so it's not as bad as I thought

[02:08:18.0000] <JakeA>
but still

[02:09:22.0000] <JakeA>
annevk: "prominent browsing context" would be either the focused window, a visible window, any window, or null? (in that order of preference?)

[02:10:35.0000] <annevk>
JakeA: yeah, something like that I guess

[02:11:07.0000] <JakeA>
I suppose as I developer I could potentially predict the outcome by looking at clients.matchAll

[02:11:34.0000] <annevk>
JakeA: alternatively we could give the developer control over the window

[02:15:31.0000] <JakeA>
annevk: that's how I came to client.fetch

[02:16:06.0000] <annevk>
JakeA: I don't think client.fetch makes sense since you'd need to branch your code depending on what you anticipate the response will be

[02:16:55.0000] <annevk>
JakeA: and that API suggests other things to me, like the client will actually run the fetch, meaning it would go through the service worker again, or some such

[02:17:26.0000] <JakeA>
annevk: it'd be 'neater' if it were part of the request. We've gone back & forward on where "client" sits. Because of caching it feels like it shouldn't be part of the request object

[02:18:01.0000] <JakeA>
annevk: true, I thought "client isn't part of the storable request, but it's part of the execution of the request", which is when I tried to build the association between the client & the fetching

[02:19:39.0000] <JakeA>
annevk: here's that header truncation issue https://code.google.com/p/chromium/issues/detail?id=244260

[02:19:52.0000] <annevk>
Depending on the outcome of that issue and how flexible this needs to be, setting a browsing context might not even be exposed...

[02:23:41.0000] <JakeA>
annevk: which issue?

[02:23:51.0000] <annevk>
119

[02:24:25.0000] <JakeA>
ahh gotcha

[02:28:03.0000] <JakeA>
annevk: I think your "any origin window" idea is good enough. Will write up the options on that ticket

[02:28:41.0000] <JakeA>
will get someone to look at that CSS CORS issue too

[02:29:08.0000] <annevk>
We still need to figure out how to update Fetch et al to catch those network-generated dialogs and surface them

[02:29:13.0000] <annevk>
But baby steps, I guess

[02:29:28.0000] <annevk>
I would prefer though that fetch() by default generates no UI still...

[02:29:51.0000] <annevk>
And ideally it never does and if you rely on HTTP auth you just implement it yourself (you can with fetch())

[02:30:06.0000] <annevk>
And if you rely on TLS client auth we need to think of something new... But maybe that one isn't feasible

[02:45:39.0000] <annevk>
JakeA: another big problem with SW is that we haven't rewritten all the features that should use Fetch, but currently invoke something else

[02:45:57.0000] <annevk>
JakeA: this makes it very unclear how they should work and handle certain types of responses

[02:46:44.0000] <JakeA>
annevk: yeah, there's some translation going on, so potentially wrong assumptions made

[02:47:19.0000] <annevk>
Well and most specs still assume the authority is with the request, whereas we shifted it to be on the response

[02:47:25.0000] <annevk>
Which is a pretty big shift

[03:40:29.0000] <annevk>
jgraham: https://critic.hoppipolla.co.uk/r/4453

[03:40:41.0000] <annevk>
hallvors: ^^

[05:31:28.0000] <Ms2ger>
Is there supposed to be a difference between "Let source be the browsing context that contains the Document object with which subject in question is associated." and "let target be the browsing context that subject itself is in." in https://html.spec.whatwg.org/multipage/semantics.html#following-hyperlinks-2 ?

[05:32:51.0000] <annevk>
Ms2ger: I think the answer is no

[05:33:01.0000] <annevk>
Ms2ger: it would be clearer if target were set to source

[05:33:05.0000] <Ms2ger>
Yeah

[05:33:27.0000] <Ms2ger>
I'd suggest that, but without an editor...

[05:34:00.0000] <annevk>
Ms2ger: there's a bunch of prose problems there

[05:34:13.0000] <Ms2ger>
Unsurprisingly :)

[05:36:29.0000] <annevk>
Ms2ger: could at least file a bug

[05:47:19.0000] <SimonSapin>
Is there a much content relying on application/xhtml+xml ? (Should Servo try to support it at all?)

[05:47:36.0000] <annevk>
It's not exactly hard, is it?

[05:49:55.0000] <Ms2ger>
We don't support XML yet :)

[05:50:08.0000] <Ms2ger>
But there's an XML5 parser now

[05:51:26.0000] <annevk>
Isn't that enough?

[05:51:27.0000] <gsnedders>
I wonder how much XML5 will break?

[05:51:38.0000] <Ms2ger>
Glue :)

[05:51:52.0000] <annevk>
It shouldn't really break anything, but who knows

[05:52:48.0000] <SimonSapin>
my point is that while we may wanna try XML5 for SVG and some other things that require an XML parser, maybe we should still not support XHTML

[05:53:43.0000] <annevk>
If you're going to have an XML parser, you should just parse everything +xml with it and not make exclusions

[05:55:05.0000] <SimonSapin>
that’s… RFC 3023 ?

[05:58:11.0000] <annevk>
https://tools.ietf.org/html/rfc7303 these days

[07:25:43.0000] <annevk>
JakeA: so the truncation issue sleevi mentioned is actually bigger when we introduce streams / cancel

[07:26:30.0000] <annevk>
JakeA: it puts an attacker in control of the contents of "no-cors" resources

[07:26:46.0000] <annevk>
JakeA: which is problematic

[07:27:45.0000] <annevk>
Well, maybe stream-wise those will be opaque so you don't get a stream... But there might be some other angle... But cancelation-wise the concerns still apply I think...

[07:29:32.0000] <JakeA>
annevk: yeah. That specific issue was down to Chrome not parsing headers properly, but maybe there are other security-sensitive formats that don't have a delimiter?

[07:31:28.0000] <JakeA>
annevk: anything you can do with .cancel() could happen by going offline. So if it's a security issue it's already a security issue, just whether it happens accidentally or deliberately.

[07:32:06.0000] <annevk>
JakeA: well, that seems somewhat absurd

[07:33:08.0000] <annevk>
JakeA: an attacker has control over cancel() and can easily try it many times without requiring the user to do anything special

[07:36:17.0000] <JakeA>
annevk: agreed. It makes the highly unlikely quite possible, but it doesn't make the impossible possible.

[07:37:00.0000] <annevk>
I guess it also depends on how we handle the cancelation in Fetch

[07:46:09.0000] <TabAtkins>
annevk: Looking into the issue today, but remember you can always force-generate.

[07:52:27.0000] <gsnedders>
"input[type=hidden i]" — am I missing something? what's that i for?

[07:56:48.0000] <TabAtkins>
Marks the value as matching CI

[08:11:24.0000] <annevk>
ASCII case-insensitive*

[08:47:25.0000] <JakeA>
Domenic: I've made a couple of mistakes in my latest cancelable promise commits, so don't worry about all the breakages. Will fix.

[09:12:21.0000] <annevk>
jochen__: any ETA on working on Referrer again?

[09:32:01.0000] <BigPants>
I don't mind standing every dayyyyyy

[09:32:11.0000] <BigPants>
out on your corner in the pouring raaaaain

[09:32:38.0000] <BigPants>
look for the girl with the broken smile

[09:32:56.0000] <BigPants>
ask her if she wants to a whiiiile

[09:33:11.0000] <BigPants>
AND SHE WIIIIILL BE LOOOOOOOVED

[09:33:55.0000] <BigPants>
Good channel for that. Totally meant it for another :P

[09:51:22.0000] <caitp>
well friday is as good a day as any for irc karaoke

[09:52:01.0000] <BigPants>
I should definitely have picked a cooler song to accidentally belt out though

[09:52:43.0000] <caitp>
the temptations is always a good pick

[10:24:44.0000] <jochen__>
annevk: i'm working on it non-stop!

[10:24:48.0000] <jochen__>
annevk: what's up with it?

[13:49:01.0000] <cvrebert>
Can someone please remove X-UA-Compatible from https://wiki.whatwg.org/wiki/PragmaExtensions ? It became an official pragma: https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-x-ua-compatible

[15:40:23.0000] <jwalden>
peoples!  if I were unsure whether getBoundingClientRect().top could ever be -0, do people think it'd make more sense to file the bug on getBoundingClientRect, or on DOMRect?


2015-07-04
[20:00:25.0000] <hgl>
when a program is able to daemonize itself. should i still use procd to start/stop it in the init script?

[20:00:45.0000] <hgl>
oops, wrong channel

[20:00:50.0000] <hgl>
sorry about that.

[12:41:53.0000] <espadrine>
I'm seeing bikeshed pending everywhichway

[12:41:55.0000] <espadrine>
eg http://dev.w3.org/csswg/selectors-4/

[12:44:29.0000] <MikeSmith>
TabAtkins: 矢印

[12:44:39.0000] <MikeSmith>
oofs

[12:46:10.0000] <MikeSmith>
↑

[12:49:32.0000] <TabAtkins>
espadrine: Poked plinss. His server gets wedged occasionally, don't know why.

[12:50:01.0000] <TabAtkins>
And he hasn't gotten around to saving the old version before generating the new one yet, so when this happens, they all go dumb.

[12:50:40.0000] <espadrine>
ok

[12:55:37.0000] <TabAtkins>
espadrine: plinss says its fixed now

[12:56:01.0000] <espadrine>
yay :D it works!


2015-07-05
[02:19:16.0000] <annevk>
TabAtkins: still waiting for a fix...

[02:27:04.0000] <annevk>
I guess it's the weekend, my bad

[03:29:18.0000] <annevk>
jochen__: there's a couple of open issues on GitHub

[03:29:24.0000] <annevk>
jochen__: about how to best integrate with service workers

[03:30:03.0000] <annevk>
jochen__: and how that affects the design of the referrer attribute (that one was also discussed on blink-dev, ended up with not implementing, though someone is still pushing it in Gecko...)

[03:30:20.0000] <annevk>
jochen__: I can't find your GitHub account though

[03:37:46.0000] <Domenic>
annevk: it's jeisinger I believe

[03:44:28.0000] <annevk>
Domenic: ta

[07:13:19.0000] <annevk>
MikeSmith: thanks for Fetch PR #71!

[07:48:49.0000] <annevk>
GitHub needs a "report spam" feature for stuff like https://github.com/whatwg/xhr/issues/22

[07:49:35.0000] <annevk>
/me finds https://github.com/contact?report=Rio-Minarino

[08:27:31.0000] <caitp>
the dude's cat probably just found their way onto the keyboard

[08:27:32.0000] <caitp>
it happens


2015-07-06
[17:46:23.0000] <weinig>
hi heycam

[17:46:32.0000] <heycam>
hi weinig

[17:46:39.0000] <weinig>
heycam: got a second for a WebIDL question?

[17:46:42.0000] <heycam>
sure

[17:47:08.0000] <weinig>
heycam: for a method like prepend in https://dom.spec.whatwg.org/#parentnode

[17:47:33.0000] <weinig>
heycam: should non-nodes that get passed to it get toString()ed?

[17:48:14.0000] <heycam>
weinig, I think that's right. let me check.

[17:48:20.0000] <weinig>
heycam: thanks!

[17:49:26.0000] <heycam>
weinig, so, yes. the last few steps of http://heycam.github.io/webidl/#es-union catch types that didn't match exactly

[17:49:40.0000] <weinig>
heycam: excellent, thanks!

[17:49:51.0000] <heycam>
weinig, no problem!

[17:50:13.0000] <weinig>
“If types includes a string type, then return the result of converting V to that type."

[17:50:18.0000] <weinig>
couldn’t be clearer :)

[17:50:38.0000] <heycam>
it's clear if you've made it all the way through the previous 15 steps :)

[17:50:56.0000] <weinig>
heycam: and remembered where to look

[17:51:07.0000] <weinig>
heycam: I was pretty sure I was right, I just couldn’t remember which part it was in

[00:26:53.0000] <jochen__>
annevk: i guess you found my github account meanwhile

[00:26:59.0000] <annevk>
jochen__: did!

[00:27:22.0000] <jochen__>
annevk: i'm not convinced that the referrer attribute adds much value, i'd rather first see a use case

[00:27:29.0000] <annevk>
jochen__: https://github.com/w3c/webappsec/issues/409 and https://github.com/w3c/webappsec/issues/413

[00:27:35.0000] <jochen__>
as in a big website that wants this feature

[00:27:38.0000] <annevk>
jochen__: well I'd be happy if you removed it from the draft

[00:28:04.0000] <annevk>
jochen__: we should still figure out what the story with fetch(), service workers, and referrers is

[00:28:35.0000] <jochen__>
yes

[00:29:23.0000] <annevk>
Setting same-origin URLs works fine, until you hit CSS. I'm not entirely sure what to do there and it seems to be a problem for service workers too. At least, the current model violates SOP (same for resource timing)...

[00:30:15.0000] <annevk>
Perhaps "no-cors" cross-origin CSS subresources should simply skip the service worker... And if you want them to go through you need CORS.

[00:30:42.0000] <jochen__>
what's the problem with css?

[00:30:58.0000] <annevk>
jochen__: https://github.com/slightlyoff/ServiceWorker/issues/719

[00:31:03.0000] <annevk>
jochen__: and https://github.com/w3c/webappsec/issues/413

[00:31:33.0000] <annevk>
jochen__: (the referrer for CSS subresources is the stylesheet, not the document)

[00:31:36.0000] <jochen__>
ah, the sheet itself is from another origin

[00:31:42.0000] <jochen__>
but the service worker sees what it loads

[00:31:48.0000] <annevk>
yeah

[00:31:56.0000] <annevk>
well, at least as currently defined

[00:32:00.0000] <jochen__>
not telling the service worker about those seems like the way to go

[00:32:31.0000] <annevk>
But I guess even with CORS CSS, setting the referrer for its subresources would be problematic

[00:32:46.0000] <annevk>
So perhaps we should only allow copying the referrer from incoming Request objects

[00:33:06.0000] <annevk>
Gotta go for a bit

[00:33:13.0000] <jochen__>
yeah, so the only actual use case I know for changing the referrer to something entirely else is G+

[00:33:32.0000] <slightlyoff>
you need to test that in the wild.

[00:33:40.0000] <jochen__>
and they don't want to set it to something on the same origin, but to something else

[00:33:55.0000] <slightlyoff>
i have a guess that font cdns care about referrer

[00:33:57.0000] <jochen__>
i.e. they would like to have plus.url.google.com as outgoing referrer

[00:34:45.0000] <slightlyoff>
(particularly the licensed kind)

[00:45:33.0000] <MikeSmith>
hayato: わあああー😲

[00:45:56.0000] <kochi>
yey!

[00:45:59.0000] <kochi>
yay!

[00:46:35.0000] <hayato>
If you are watching GitHub w3c/webcomponents repository, I'm very sorry for spamming :)

[00:46:59.0000] <MikeSmith>
now he says he's sorry! :-)

[00:47:26.0000] <hayato>
In the next, I'll mark all migrated bugs on bugzilla "MOVED".

[00:47:49.0000] <MikeSmith>
yay! nice to have something to look forward to!

[00:48:03.0000] <MikeSmith>
hayato: just kiddingーI'm very glad to see these getting migrated to github

[00:48:08.0000] <MikeSmith>
thanks for doing it

[01:04:42.0000] <annevk>
jochen__: so the problem is that service workers reset the referrer due to fetch()

[01:04:58.0000] <annevk>
jochen__: so for a site with a service worker the referrer will always be the service worker

[01:05:21.0000] <annevk>
jochen__: I think we want that to change

[01:07:50.0000] <MikeSmith>
oops in hindsight I guess we should have temporarily disabled bugzilla bugmail to public-webapps

[01:07:56.0000] <MikeSmith>
too late now I reckon

[01:10:49.0000] <annevk>
I guess I'm gonna mark w3c/webcomponents as read

[01:10:53.0000] <annevk>
That's too much

[01:11:01.0000] <Domenic>
I thought we did disable it...

[01:14:43.0000] <annevk>
Yeah, not super cool this

[01:19:10.0000] <MikeSmith>
Domenic: yeah was just now talking to the webapps team contact; it seems they disabled it on the component but not on all the existing bugs

[01:23:32.0000] <hayato>
Hmm. it looked public-webapps received the mass mail flood again.

[01:24:09.0000] <hayato>
Sorry for that. I though the mail was disabled as per https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0006.html

[01:24:48.0000] <hayato>
Yes, I've finished.

[01:27:25.0000] <hayato>
xiaoqian told me that it was not removed from *every* bugs.

[01:27:37.0000] <MikeSmith>
hayato: no worriesー not your fault, yeah

[01:28:19.0000] <MikeSmith>
I should have checked on it myself ahead of time

[01:29:29.0000] <Domenic>
annevk: would it be interesting to have GitHub auto-notify about commits to whatwg repos in this channel? Or would that interfere with the flow of discussion?

[01:29:42.0000] <annevk>
jochen__: it seems kind of okay to tie the referrer thing to public suffixes, though sleevi might have a fit :p

[01:30:05.0000] <annevk>
Domenic: might be fun to try

[01:30:26.0000] <hayato>
MikeSmith:  NP. I also should have tested it with a small number of the bugs. If we have a next chance, I think we can do better in the next time. :)

[01:31:01.0000] <Domenic>
I guess people can already watch those with twitter, hmm

[01:31:38.0000] <MikeSmith>
hayato: no blood was spilled, so I think everybody will survive :)

[01:36:40.0000] <annevk>
MikeSmith: "e.g." is usually followed by a comma?

[01:37:04.0000] <MikeSmith>
annevk: yeah, it always is, actually

[01:37:20.0000] <annevk>
MikeSmith: huh, okay

[01:37:33.0000] <annevk>
MikeSmith: "forbidden response-header name" why no hyphen after forbidden?

[01:37:37.0000] <MikeSmith>
Just like "for example" is

[01:38:09.0000] <annevk>
MikeSmith: or between same-origin and data-URL in "same-origin data-URL flag"

[01:39:57.0000] <MikeSmith>
well those are sorta special cases, in part because they're unambiguous without yet another hyphen in there

[01:40:57.0000] <MikeSmith>
I think they might actually be more confusing if there were additional hyphens there

[01:42:45.0000] <MikeSmith>
because "same-origin" is a unit of meaning as a term, and "data url" is a unit ofmeaning as a term

[01:43:12.0000] <MikeSmith>
The extra hyphen would obscure those meanings

[01:44:01.0000] <MikeSmith>
if y'all do set up IRC notifications for any github repos here, I recommend you use the github option to send them as IRC Notices rather than regular messages (that would show up as "real" channel activity in people's clients)

[01:45:47.0000] <hayato>
I'll send an announce mail about the migration to public-webapps soon after I update the links to the bugs on the Custom Elements and HTML Imports editor's draft.

[01:45:57.0000] <MikeSmith>
and "forbidden response-header name" because I think you also already got "response-header name" there as a term

[01:46:20.0000] <MikeSmith>
So "forbidden" is modifying that existing term

[02:27:38.0000] <Domenic>
annevk: how do you convert svgs to pngs usually

[02:27:56.0000] <annevk>
Domenic: I use some online service, but reportedly it's not very good

[02:28:12.0000] <Domenic>
I can use an optimizer after the initial conversion, just need to get that done

[02:28:16.0000] <annevk>
Domenic: as in, I use one of the first search results for that question

[02:28:44.0000] <annevk>
Domenic: and I use 500x500 as output size, to avoid most scaling artifacts

[02:29:05.0000] <Domenic>
and what is the best png crusher these days... eric lawrence has opinions, i know

[02:29:47.0000] <annevk>
I guess if you're on Windows you can use his stuff

[02:30:01.0000] <annevk>
The only reason we even have PNG is Twitter

[02:31:58.0000] <Domenic>
They probably recompress to jpg anyway lol

[02:41:55.0000] <annevk>
davve: Domenic: hah, I see now why it had the extra <path> bits, the original didn't render in Firefox

[02:42:03.0000] <annevk>
I wonder what caused that

[03:08:45.0000] <Domenic>
yeah that seems kind of bad

[04:36:46.0000] <MikeSmith>
SimonSapin: regarding application/xhtml+xml, https://bugzilla.mozilla.org/show_bug.cgi?id=1180623 seems relevant to what you were asking about the other day, as far as if there's content relying on application/xhtml+xml and if Servo should support it

[04:37:52.0000] <MikeSmith>
SimonSapin: as far as I can tell from the bug description that Julien wrote there, mobile GMail at least must be using application/xhtml+xml for something for some reason

[04:39:31.0000] <MikeSmith>
of course that bug's also relevant in the context of what should be done in cases where the application/xhtml+xml being served isn't well-formed XML

[04:43:41.0000] <MikeSmith>
anyway we still have to wonder (1) why Gmail is serving anything as application/xhtml+xml to begin with, and (2) whatever UAs they're intending it for must not actually be parsing it as XML, because otherwise they'd be choking on it too, so why don't they just serve it as text/html to them

[05:23:55.0000] <SimonSapin>
thanks for the pointer MikeSmith

[05:27:11.0000] <annevk>
philipj: not sure how to answer your window.event questions

[05:27:52.0000] <philipj>
annevk: to put it differently, is there anything I can do?

[05:29:05.0000] <philipj>
if there's a particular pattern of usage seen in some bug report, I could search for that in httparchive

[05:29:36.0000] <philipj>
but coming up with a use counter that's a good proxy of the risk seems tricky in this case

[05:34:12.0000] <Domenic>
SimonSapin: Ms2ger: why is Servo doing XML5 instead of just HTML?

[05:40:12.0000] <Ms2ger>
I would be very surprised if we never needed any xml

[05:46:38.0000] <jgraham>
Although I think the answer to "why now" is more or less "someone wrote a patch"

[05:50:39.0000] <Domenic>
Ms2ger: why? assuming "HTML" = HTML + SVG (+ MathML if you want)

[05:51:37.0000] <jgraham>
Because XML does occasionally get used? Not just through top-level documents

[05:52:00.0000] <jgraham>
I mean Chrome can't even remove XSLT afaik which is even less common

[05:52:00.0000] <Domenic>
But ... you have no concrete examples?

[05:52:25.0000] <Domenic>
IIRC XSLT and SVG are the only things in chrome we need libxml for

[05:53:13.0000] <Domenic>
Seems like a lot to add to a browser without any actual use cases yet, is what confuses me.

[05:53:19.0000] <JonathanNeal>
Hypothetically, would the selector weight of `.element:media( min-width: 30em )` be any heavier than the selector weight of `.element` ? Re: http://htmlpreview.github.io/?https://github.com/ResponsiveImagesCG/container-queries/blob/master/index.html

[05:54:02.0000] <jgraham>
https://golem.ph.utexas.edu/~distler/blog/ is a concrete example

[05:54:59.0000] <Domenic>
jgraham: sure, but that can be parsed with the HTML parser

[05:55:12.0000] <Domenic>
No need for XML5

[05:56:45.0000] <jgraham>
It's not obvious to me that's true without trying it

[05:57:02.0000] <jgraham>
But we at least all agree that you today can't ship a browser without XML support

[05:57:46.0000] <jgraham>
And someone offered to implement XML5 in a way that would integrate with Servo

[05:57:57.0000] <jgraham>
So I'm not sure what the discussion here is

[05:58:31.0000] <Domenic>
jgraham: I tried it in IE, it works fine

[05:59:25.0000] <Domenic>
jgraham: if this is just a way of helping a new collaborator feel welcomed, that's fine. I'm questioning whether XML is actually something the web platform needs, and surprised Servo's answer is "yes, and also we invented a new dialect of it that nobody else supports."

[05:59:34.0000] <benjamingr>
mathiasbynens: hey, if you're here by any chance we have a RegExp with 'u' flag question for you :)

[05:59:40.0000] <Domenic>
We're actively trying to remove it in Chromium.

[06:01:14.0000] <jgraham>
If you manage to remove it in Chromium then I'm sure people will be happy to turn it off in Servo

[06:01:33.0000] <jgraham>
Servo isn't exactly in a position to influence content authors today

[06:01:58.0000] <Domenic>
Fair enough

[06:01:58.0000] <jgraham>
OTOH XML5 seems like an experiment worth running

[06:02:19.0000] <Domenic>
IE never implemented it for HTML, is also my point.

[06:03:35.0000] <Domenic>
But I guess it's all the rage to be compatible with WebKit/Blink these days instead of Gecko or IE :-/

[06:05:31.0000] <mathiasbynens>
benjamingr: shoot

[06:06:25.0000] <benjamingr>
mathiasbynens: we're working on RegExp.escape and we're wondering if/why we need to escape a-fA-F at the start of terms. https://github.com/benjamingr/RegExp.escape/pull/35

[06:06:38.0000] <mathiasbynens>
Domenic: iirc IE does support XHTML nowadays but sure, long after people stopped caring

[06:06:58.0000] <Domenic>
mathiasbynens: hmm I was almost certain I read some Edge stuff on them doubling-down on not supporting XHTML

[06:07:51.0000] <gsnedders>
IE added support in 8 or something

[06:08:00.0000] <Domenic>
ah yep, my bad, in version 9. http://blogs.msdn.com/b/ie/archive/2010/11/01/xhtml-in-ie9.aspx

[06:11:55.0000] <benjamingr>
mathiasbynens: thanks, are there any special cases we need to be aware of with the "u" flag?

[06:12:53.0000] <philipj>
Domenic: in terms of usage getting rid of XSLT seems like a possibility, but that blink-dev thread sure did generate a lot of negative feedback

[06:13:24.0000] <Domenic>
philipj: we did showModalDialog, I am (over-)optimistic that if we take a bit to recover we can do XSLT :)

[06:13:26.0000] <philipj>
assuming that XSLT is gone, do you have any hunch about the additional risk of scrapping XML as a whole, e.g. by replacing it by some new (or old?) HTML insertion mode?

[06:13:50.0000] <Domenic>
my hunch is that we can't know before we try parsing SVG as HTML

[06:14:13.0000] <Domenic>
I see no obvious problems with that, but it really needs to be tried before we can say anything

[06:14:33.0000] <philipj>
That does seems pretty doable, since it already happens for SVG in HTML

[06:14:56.0000] <Domenic>
After SVG and XSLT... I guess the news that IE has been supporting XHTML syntax since version 9 is a bit worrying

[06:15:03.0000] <Domenic>
But most people write their XHTML as "polyglot"

[06:15:19.0000] <philipj>
In other contexts, I guess there's little chance of content depending on XML parsing to fail, so it's down to cases where a new HTML parser mode would result in a different DOM than an XML parser

[06:15:27.0000] <Domenic>
Yeah, stuff like <div />

[06:15:58.0000] <philipj>
Yeah :/

[06:16:09.0000] <Domenic>
But as I said, mostly polyglot, probably fine...

[06:16:14.0000] <philipj>
Probably

[06:16:26.0000] <Domenic>
After SVG, XSLT, XHTML, I don't think there's anything left...

[06:16:51.0000] <philipj>
Getting rid of XSLT seems worthwhile on its own, since that also adds a libxslt dependency

[06:16:53.0000] <Domenic>
Chrome doesn't support RSS (and I hear that needs a forgiving parser these days anyway)...

[06:17:17.0000] <Domenic>
+1

[06:17:35.0000] <philipj>
So you just need to trick someone into thinking that removing XSLT is a good way to get love and praise from web developers

[06:18:40.0000] <philipj>
Usage:

[06:18:42.0000] <philipj>
https://www.chromestatus.com/metrics/feature/timeline/popularity/78

[06:18:48.0000] <philipj>
https://www.chromestatus.com/metrics/feature/timeline/popularity/79

[06:19:33.0000] <Domenic>
Are there warnings yet?

[06:19:56.0000] <philipj>
Nope

[06:20:11.0000] <Domenic>
0.005 seems risky but maybe it could be cut further with warnings

[06:20:41.0000] <philipj>
Deprecation messages don't seem very effective, but if we add in a date of removal and make it a very long deprecation window (a year?) it might work out

[06:20:48.0000] <Domenic>
But, I imagine we shouldn't do this until the team has had more time to recover from showModalDialog; that took a lot of fortitude.

[06:21:33.0000] <Domenic>
Hmm, I feel like I saw several graphs where deprecation messages made a difference. Maybe it was just showModalDialog though.

[06:21:33.0000] <philipj>
Yeah, I'm not volunteering to tackle this at least, not now :)

[06:22:32.0000] <philipj>
Well, sometimes my best explanation for a big drop has been "maybe someone saw a warning", but in most cases it seems to make no difference at all

[06:22:49.0000] <philipj>
In particular when usage is already low that's to be expected, because very few people will even see the warning

[06:25:15.0000] <MikeSmith>
I believe hsivonen_ is one of the people who's been opposed to the "solution" of parsing application/xhtml+xml through the HTML parser

[06:26:41.0000] <MikeSmith>
he's suggested that if we're going to do something about the problem, it should be to implement XML5 parsers

[06:27:12.0000] <MikeSmith>
i.e., pretty much what the Servo team is trying (as far as I understand)

[06:27:22.0000] <mathiasbynens>
benjamingr: i think the patch covers it

[06:27:37.0000] <philipj>
Might it be an option to make an XML5 parser as a mode of the HTML parser?

[06:27:42.0000] <benjamingr>
mathiasbynens: thanks!

[06:27:51.0000] <mathiasbynens>
benjamingr: only other thing that’s important here is \u{…} syntax which i believe is already covered by escaping 0-9a-fA-F

[06:28:23.0000] <Domenic>
MikeSmith: hmm now I am trying to figure out what the differences are between XML5 parsing XHTML and the HTML parser parsing XHTML

[06:28:42.0000] <Domenic>
MikeSmith: I guess if XML5 is just XML with error handling, then it would treat <div/> as <div></div>

[06:28:50.0000] <benjamingr>
mathiasbynens: thanks! Any feedback on the repo and proposal would be greatly appreciated in general.

[06:28:55.0000] <MikeSmith>
Domenic: see https://bugzilla.mozilla.org/show_bug.cgi?id=1044332#c5 for Henri's comments < philipj

[06:29:08.0000] <philipj>
MikeSmith: thanks!

[06:29:27.0000] <MikeSmith>
Domenic: yeah I think so. But we don't have to speculate because there's actually a spec

[06:29:34.0000] <MikeSmith>
/me looks for the current spec URL

[06:30:25.0000] <MikeSmith>
I think the dev who implemented the Sever XML5 parser worked from Anne's XML5 spec but updated the spec in teh process

[06:30:37.0000] <Domenic>
MikeSmith: well, "I'd rather see e.g. Blink bear the cost of trying something as radical as getting rid of XSLT or XML parsing instead of us bearing the cost of discovering the impact of such feature removals from the platform." heh

[06:30:45.0000] <philipj>
Domenic: "Google Maps was what forced some other engines to add XSLT after Trident and Gecko..." says https://bugzilla.mozilla.org/show_bug.cgi?id=1044332#c5

[06:30:53.0000] <philipj>
Any idea if they're still a user?

[06:31:04.0000] <MikeSmith>
/me has no idea

[06:31:37.0000] <Domenic>
philipj: seems unlikely... if they were we could probably wipe out the remaining 0.005 with one well-placed internal cake delivery, haha

[06:32:26.0000] <philipj>
It does seem unlikely, indeed. On that topic, getting data on which URLs actually trigger use counters would provide a path forward on many issues like this

[06:33:23.0000] <MikeSmith>
but the context of some recent gecko bugs over the last couple years is that Gmail is sending application/xhtml+xml for some things to some mobile UAs, including Firefox Mobile

[06:33:52.0000] <philipj>
MikeSmith: Opera Presto had the same problem, and fixed it by reparsing as HTML I think

[06:34:10.0000] <MikeSmith>
philipj: yeah that's not a fix though

[06:34:24.0000] <philipj>
Well, not a nice one :)

[06:34:45.0000] <MikeSmith>
yeah, but also because it just doesn't work in many cases

[06:34:56.0000] <MikeSmith>
I think it also has security issues

[06:35:33.0000] <philipj>
I don't know in which contexts it would happen, but apparently it worked well enough for us to attempt it

[06:35:47.0000] <philipj>
Although maybe there was a button one had to press to reparse as HTML, I can't recall

[06:35:51.0000] <MikeSmith>
we should try to get Ygg01 on here (dev who implemented XML5 parsing for Servo)

[06:35:52.0000] <philipj>
Doesn't matter now, anyway

[06:35:56.0000] <MikeSmith>
yeah

[06:36:00.0000] <MikeSmith>
https://github.com/Ygg01

[06:36:14.0000] <MikeSmith>
Domenic: philipj https://github.com/Ygg01/xml5_draft

[06:36:26.0000] <MikeSmith>
https://ygg01.github.io/xml5_draft/

[06:36:33.0000] <Domenic>
philipj: https://www.chromium.org/developers/design-documents/rappor may help, but on the other hand it seems like it might fail in precisely these low-numbers use cases

[06:38:14.0000] <MikeSmith>
Ygg01 also has an XML5 test suite at https://github.com/Ygg01/xml5lib-tests

[06:38:31.0000] <philipj>
Domenic: I've been hearing about Rappor+UseCounter for a while now, but nothing has surfaced outside of Google at least.

[06:39:48.0000] <MikeSmith>
the spec at https://ygg01.github.io/xml5_draft/ is modified from the XML5 spec that Anne originally wrote, and I recall that the changes to it that Ygg01 were also discussed with Anne

[07:12:16.0000] <annevk>
"just HTML" is not a solution that actually works for SVG, XMLHttpRequest, etc.

[07:13:03.0000] <annevk>
Seems far too difficult to do anything like that. XML5 + enhancements is a much saner path...

[07:14:03.0000] <annevk>
philipj: I don't know :-/

[07:14:22.0000] <annevk>
philipj: counting the getter was what I would have suggested, but that seems to return surprising results

[07:15:15.0000] <philipj>
annevk: indeed. one could also count only the cases where it returns something other than undefined, but I'd be surprised if that came back with a tiny number

[07:15:35.0000] <philipj>
how badly do you want to avoid spec'ing this and adding it to Gecko?

[07:16:04.0000] <annevk>
philipj: well, DOM peers have stated they don't want to add it

[07:16:42.0000] <annevk>
philipj: and it's not exactly a sane extension of the event model, so I guess I'd like to avoid it pretty badly

[07:32:55.0000] <Domenic>
annevk: I am not convinced "just HTML" does not work. But we will see.

[07:34:04.0000] <SimonSapin>
Domenic: wanna try it in Canary? :)

[07:34:19.0000] <SimonSapin>
We can try it in Servo, but results won’t be as conclusive…

[07:35:01.0000] <Domenic>
SimonSapin: I do! I am not the right expertise for that though. I think TabAtkins was mentioning trying it for SVG recently...

[07:42:08.0000] <philipj>
annevk: well, ok, do you know of any site compat issues in Gecko due to it not being supported? that would be a good indicator of what would break with removal...

[07:42:20.0000] <annevk>
philipj: no, that's the thing

[07:42:43.0000] <philipj>
nothing at all? very strange

[07:43:07.0000] <annevk>
philipj: there might have been one report, linked from that Bugzilla ticket

[07:43:10.0000] <philipj>
do you know if anyone has looked into the history of it, who added it first and why it was copied?

[07:43:30.0000] <annevk>
Domenic: it needs to be more than "just HTML", the processing model can't be that of text/html

[07:43:39.0000] <annevk>
Domenic: at least not as text/html stands today

[07:43:57.0000] <annevk>
philipj: it's part of Microsoft's legacy event model

[07:44:18.0000] <annevk>
philipj: Opera/WebKit copied it for some reason

[07:44:35.0000] <annevk>
philipj: I guess they hit some IE code paths that Gecko did not

[07:44:49.0000] <philipj>
annevk: I guess finding that reason would be interesting, but takes a bit of work

[07:45:02.0000] <annevk>
philipj: there's a pretty long discussion in BTS about removing it too

[07:45:22.0000] <philipj>
annevk: bugs.opera.com?

[07:45:26.0000] <annevk>
philipj: yeah

[07:45:31.0000] <philipj>
link?

[07:45:36.0000] <annevk>
philipj: Joao might know

[07:45:40.0000] <annevk>
I no longer have access

[07:45:51.0000] <philipj>
Makes sense :)

[07:46:31.0000] <philipj>
OK, found it

[07:46:44.0000] <annevk>
I had access until the Blink thing happened, didn't really make sense to me anymore at that point, but I guess it would've been useful still from to time for historical perspective

[07:47:10.0000] <philipj>
well here Joao says "window.event goes hand with hand with attachEvent" and attachEvent is long gone

[07:47:28.0000] <philipj>
if it was ever supported in Presto or WebKit, I don't know

[07:48:03.0000] <annevk>
attachEvent used to be supported in Presto at least

[07:49:18.0000] <philipj>
you're right, looks like it was 'til the end

[08:39:57.0000] <annevk>
MikeSmith: you still around?

[08:40:07.0000] <annevk>
MikeSmith: I wonder why you didn't add hyphens for "HTTP network fetch"

[08:45:32.0000] <MikeSmith>
annevk: I reckon I just overlooked that one

[08:45:54.0000] <MikeSmith>
Will take a look when I get back to my pc

[08:46:15.0000] <annevk>
MikeSmith: I'm going to commit this first pass in a bit, I guess I can leave the issue open

[08:46:22.0000] <MikeSmith>
k

[09:27:08.0000] <MikeSmith>
annevk: yeah not sure how I missed that

[09:28:23.0000] <MikeSmith>
"HTTP network or cache fetch" definitely should be "HTTP-network-or-cache fetch"

[09:28:48.0000] <MikeSmith>
and so "HTTP network fetch" should be "HTTP-network fetch"

[09:28:56.0000] <MikeSmith>
will make another PR

[09:29:07.0000] <MikeSmith>
and also see if there's any others I missed

[09:29:26.0000] <annevk>
MikeSmith: I listed a couple of likely candidates

[09:30:37.0000] <MikeSmith>
oh

[09:30:38.0000] <MikeSmith>
where?

[09:30:57.0000] <MikeSmith>
"HTTP new header syntax" should be "HTTP new-header syntax"

[09:31:49.0000] <annevk>
MikeSmith: https://github.com/whatwg/fetch/issues/63#issuecomment-118905099

[09:31:54.0000] <annevk>
MikeSmith: gotta go for a bit now

[09:31:54.0000] <MikeSmith>
/me looks

[09:31:58.0000] <MikeSmith>
hai

[09:40:23.0000] <JonathanNeal>
Once upon a time, I recall there being hypothetical pseudo-classes like :section and :heading. What happened to those?

[09:42:51.0000] <TabAtkins>
Domenic: The *other* Dominic is now kinda-sorta in charge of investigating ripping out our XML implementation and replacing with something else. "Just HTML" for SVG is the leading option there, but it doesn't work for the other cases; we're looking at XML5 or the Sky parser.

[09:44:12.0000] <TabAtkins>
"Just HTML" should work for pretty much all SVG in the wild.  Not sure what it does to arbitrary namespaces for scripting.

[09:46:16.0000] <TabAtkins>
annevk: Sorry for the delay in Bikeshed fixes; got wrapped up in more holiday stuff than I anticipated, and so didn't get time to work on BS.  Will handle it this morning when I get into the office.

[09:56:34.0000] <JonathanNeal>
TabAtkins: you were the one who told me about :section and :heading - are they dead? Replaced by custom selectors?

[10:25:34.0000] <TabAtkins>
JonathanNeal: Yeah.

[11:18:31.0000] <TabAtkins>
annevk: For real, tho, just force-generate your spec if Bikeshed is erroring incorrectly.  `bikeshed -f spec`.  It tries its best to fail gracefully and minimally when you force-generate.

[11:41:54.0000] <TabAtkins>
So, good idea or bad idea: I need context information from a class to do some functions properly, but most/all can *also* be done without that context info. So I'd like to both have all the functions as methods, *and* as unbound functions that don't need a class passed in.

[11:42:46.0000] <TabAtkins>
(Main reason for this is that I've already written them all as unbound methods, and used them throughout my codebase, and don't want to have to rewrite everything to use an object, even tho the object is available everywhere I'm using these functions.)

[11:43:09.0000] <TabAtkins>
Python's metaprogramming is... shifty, and I'm not sure how crazy this idea is in it.  In JS I'd be able to handle it no problem.

[11:55:18.0000] <jwalden>
(repeating from Friday)  peoples!  if I were unsure whether getBoundingClientRect().top could ever be -0, do people think it'd make more sense to file the bug on getBoundingClientRect, or on DOMRect?

[11:55:45.0000] <annevk>
jwalden: file bugs on the former, but also the latter if it's unclear about negative values

[11:55:55.0000] <annevk>
jwalden: forgot to reply earlier, sorry

[11:55:55.0000] <jwalden>
k

[11:56:05.0000] <jwalden>
no worries :-)

[11:56:48.0000] <jwalden>
I mean, this was clearly P0 and all, but somehow the world managed to carry on

[11:59:04.0000] <jgraham>
TabAtkins: If you have an object instance you can call static methods on it, no problem

[12:00:01.0000] <jgraham>
(otoh, I am not a big fan of static methods at the best of toimes; the python idiom is just to use a function)

[12:01:14.0000] <TabAtkins>
jgraham: They're *currently* all functions and called as such, and I'm trying to avoid rewriting the world just to attach some of them to an object as well.

[12:05:03.0000] <annevk>
TabAtkins: "just HTML" clearly doesn't work for all SVG in the wild due to the <html> and <body> elements you get for free and the sizing that implies

[12:05:13.0000] <annevk>
TabAtkins: unless something changed about CSS' layout model that I missed

[12:05:33.0000] <JonathanNeal>
CSS has locked densities for pixels, right? Does that mean there is no equivelent to a dp: Density-independent Pixel?

[12:06:12.0000] <jgraham>
TabAtkins: Seems like you can just import the module they're in and call them rather than doing magic

[12:06:22.0000] <jgraham>
(I meean magic also works, but I can't recommend it)

[12:08:23.0000] <TabAtkins>
jgraham: Yeah, I'm already doing that.  Let me elaborate: Because LXML sucks, I have a module that reimplements useful parts of DOM on top of LXML's stupid tree API.  You pass the element you're working on as the first argument, etc.

[12:09:24.0000] <TabAtkins>
But some of the methods can do more if given appropriate context. For example, my check for whether something is an "opaque" element (shouldn't have its contents processed, like <script>) defaults to just a few HTML elements, but Bikeshed lets you specify custom elements as opaque, if you're gonna do processing on them in another tool afterwards.

[12:09:56.0000] <TabAtkins>
That metadata is stored on the document. I could move all the DOM methods to the document class, but then I'd have to rewrite every usage of them to call off of the document object, while today they're just function calls.

[12:10:31.0000] <TabAtkins>
Thinking of just putting them all under a document class, then using metaprogramming to define function equivalents of all of them that pass None as the self arg for you, so I dont' need to make any code changes.

[12:22:37.0000] <TabAtkins>
annevk: Sorry, when I say "just HTML", I'm implying "with minor parser changes to recognize <svg> as the first tag and switch directly to the foreign-content parser rather than generating the HTML implied elements".

[12:26:45.0000] <jwalden>
filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28918

[12:27:15.0000] <TabAtkins>
JonathanNeal: What do you mean?

[12:27:46.0000] <JonathanNeal>
I don’t think I knew what I meant. I was just learning about Android’s DP unit and trying to understand it in the context of CSS.

[12:29:08.0000] <TabAtkins>
Android's dp unit is basically equivalent to the px unit.

[12:29:34.0000] <TabAtkins>
In that it gives an angular-based measurement of the screen, so that you subtend the same visual space on different-resolution devices.

[12:29:48.0000] <JonathanNeal>
Yeap.

[12:32:02.0000] <jwalden>
px got redefined to be non-angular, didn't it?

[12:39:44.0000] <jwalden>
also filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28919 for the DOMRect side of things

[12:53:40.0000] <TabAtkins>
jwalden: It got defined to be a fixed ratio with the "in" unit.  Whether that means it's no longer an angular measure, or that "in" is now an angular unit, depends on what unit you're anchoring the set with.

[12:56:10.0000] <boogyman>
jwalden: what's the difference between 0 and -0?

[12:56:34.0000] <TabAtkins>
boogyman: The sign.

[12:56:34.0000] <TabAtkins>
^_^

[12:56:37.0000] <jwalden>
boogyman: divide a finite number by either

[12:56:47.0000] <jwalden>
boogyman: 1 / 0 === Infinity; 1 / -0 === -Infinity

[12:57:08.0000] <boogyman>
cheers

[12:57:17.0000] <jwalden>
boogyman: short of such division, or a copysign sort of operation, or in JS Object.is that compares using SameValue semantics, it's not super-observable

[12:57:43.0000] <jwalden>
but we must never forget that it is a spec we are expounding

[12:57:50.0000] <jwalden>
;-)

[13:19:51.0000] <jsbell>
Ms2ger: while you're reviewing: https://critic.hoppipolla.co.uk/r/5430

[13:19:56.0000] <jsbell>
(also: thanks!)

[13:21:49.0000] <Ms2ger>
Oh yes, that

[13:22:14.0000] <Ms2ger>
I'm wondering if we should just always use the \\btestharness.js pattern

[13:23:02.0000] <jsbell>
Ms2ger: I don't know the history of how clever we're trying to be, but sgtm

[13:23:34.0000] <Ms2ger>
jgraham, ^

[13:36:43.0000] <jsbell>
Ms2ger/jgraham: what's the process/timeline for updating the rev of testharness.js that wpt pulls in as a  submodule? Anything I should do?

[13:46:11.0000] <jgraham>
jsbell: It's just "commit the submodule update and push", if you can do that, or ask someone who can if you can't

[13:47:40.0000] <jgraham>
I guess I don't really know what the right thing to do with that PR is; I think it's fine as is, but it's maybe a matter of taste if we go with the more strict version where possible


2015-07-07
[17:47:51.0000] <TabAtkins>
annevk: By the by, this Bikeshed bug is harder than I thought. The code in question *never* worked, and I have no idea how it passed this whole time; clearly I changed something vaguely related that previously let it hide.

[17:47:58.0000] <TabAtkins>
Trying to rewrite it all *properly* now.

[17:50:48.0000] <Domenic>
TabAtkins: aww, I was hoping it was my opaque elements bug that gave you the epiphany

[17:51:09.0000] <TabAtkins>
No, that one was a super-easy "same code in two places, only updated one" bug.

[17:51:26.0000] <TabAtkins>
I just agonized on how to merge the two bits some.

[19:11:16.0000] <gsnedders>
Ms2ger: (on the assumption you're still reading logs, hi!) Servo #6564 is surely going to be too expensive to add telemetry for in Gecko?

[23:34:50.0000] <SimonSapin>
gsnedders: would it be significant to only measure in, say, 1% of calls?

[02:14:20.0000] <annevk>
TabAtkins: aww shit

[02:14:28.0000] <annevk>
TabAtkins: I guess I might have to try this -f flag then

[02:16:44.0000] <TabAtkins>
annevk: I'll work on it more tomorrow, but I also have a talk to deliver that'll eat up a bunch of my day.

[02:17:05.0000] <annevk>
TabAtkins: if it helps, notifications.bs hits this too

[02:17:18.0000] <annevk>
TabAtkins: seems to be something about optional arguments

[02:17:22.0000] <TabAtkins>
But yeah, I force generate all the time when Bikeshed is baking and I don't have time to fix it.

[02:17:27.0000] <TabAtkins>
Balking

[02:17:48.0000] <TabAtkins>
Yeah, some code about arguments is fucked.

[02:18:02.0000] <annevk>
At some point when we're somewhat closer time-wise I should also work on some warning stuff with you I guess

[02:18:17.0000] <annevk>
Gotta go too now for a bit

[02:18:39.0000] <TabAtkins>
Sure

[04:23:13.0000] <Ms2ger>
philipj, so Chromium is writing wpt tests for ChildNode#before and friends, right?

[04:25:48.0000] <philipj>
Ms2ger: yes, in https://codereview.chromium.org/1085843002/

[04:26:07.0000] <Ms2ger>
\o/

[04:26:44.0000] <Ms2ger>
And submitting them upstream?

[04:26:45.0000] <philipj>
Ms2ger: If someone creates a wpt review, will you review them?

[04:26:48.0000] <Ms2ger>
Yes

[04:27:04.0000] <philipj>
I've just asked the patch author to join this channel, will see if he wants to do it or not

[04:27:15.0000] <Ms2ger>
Hi paritosh-in_

[04:27:23.0000] <paritosh-in_>
Hi

[04:29:55.0000] <philipj>
paritosh-in_: would you like to create a pull request for https://github.com/w3c/web-platform-tests with your tests?

[04:31:19.0000] <paritosh-in_>
philipj: Yeah I'll create it

[04:32:36.0000] <philipj>
Yay, and Ms2ger has promised to review :)

[04:32:55.0000] <Ms2ger>
I'll even review quickly, because I want them in Servo :)

[04:33:31.0000] <philipj>
Ms2ger: Do you have a system in Mozilla for streamlining the process? It's a bit tedious to create local tests, commit, upstream, wait for them to trickle down, then delete the local tests

[04:34:00.0000] <Ms2ger>
Yeah, we can just commit straight into the local copy, and they get landed upstream automatically on the next sync

[04:34:26.0000] <philipj>
Ms2ger: Oh, so you automatically copy local changes into the upstream?

[04:34:29.0000] <Ms2ger>
Yep

[04:34:40.0000] <philipj>
That's pretty neat, and novel

[04:36:10.0000] <Ms2ger>
It's amazing :)

[04:37:42.0000] <jgraham>
\o/

[04:40:15.0000] <Ms2ger>
All thanks to jgraham, of course

[04:42:38.0000] <paritosh-in_>
Ms2ger & philpj: When I'll create pull request, Is it btter to separate js file from .html as done for remove tests, or will leave as it is in https://codereview.chromium.org/1085843002/

[04:42:40.0000] <paritosh-in_>
?

[04:43:56.0000] <Ms2ger>
I would have separated them myself, but I won't complain about it

[04:44:47.0000] <Ms2ger>
One thing is that it seems nicer to pass child/innerHTML to the function as arguments, rather than define them based on the nodeName

[04:46:21.0000] <smaug____>
Ms2ger: I'm still a tad worried about getting proper reviews for wpt tests

[04:46:32.0000] <smaug____>
but I guess we'll see how this all goes

[04:46:40.0000] <smaug____>
probably just fine

[04:47:01.0000] <smaug____>
/me should be more optimistic

[04:47:28.0000] <Ms2ger>
Me too, but I'm more worried about getting no tests :)

[04:47:56.0000] <Ms2ger>
People are a lot more willing to point out something is wrong on the internet than writing tests themselves :)

[04:48:01.0000] <paritosh-in_>
Ms2ger: ok I'll take this

[04:48:06.0000] <Ms2ger>
Thank you!

[04:49:29.0000] <jgraham>
The theory is that if lots of people would run the tests we will either notice each other's mistakes eventually, or bake the mistake into the platform in a consistent way, in which case we have to change the spec.

[04:49:58.0000] <jgraham>
This does depend on more than just gecko + servo running the tests ofc, but it seems like Blink is making some progress again

[04:51:04.0000] <smaug____>
yeah, if Gecko and Blink run the tests all the time, this should be rather safe setup

[06:25:44.0000] <gsnedders>
SimonSapin: I thought you guys mostly didn't sample, but yeah, that owuld likely suffice, though possibly still a surprising performance penalty, tbh

[06:41:19.0000] <philipj>
paritosh-in_: did you send a pull request already? I'd like to follow the review even if Ms2ger does the work

[06:44:12.0000] <paritosh-in_>
philipj: no, till now I have'nt sent it.

[06:46:02.0000] <philipj>
paritosh-in_: what do you mean, weren't you going to create it?

[06:51:35.0000] <paritosh-in_>
philipj: yeah, I'll create it

[07:04:29.0000] <Ms2ger>
paritosh-in_, ping me when you do?

[07:04:33.0000] <annevk>
philipj: so technically if it already passed Blink review, that might be enough so it doesn't also need wpt review

[07:04:44.0000] <annevk>
philipj: that's at least what we do for Gecko wpt stuff I think

[07:07:25.0000] <philipj>
annevk: yeah, linking to the original review would be a good start at least

[07:07:38.0000] <philipj>
in this case, I did the original review, so someone competent should take a second look :P

[07:07:47.0000] <Ms2ger>
philipj, I'd like to see it first :)

[07:08:39.0000] <annevk>
Nobody knows why Opera pays philipj, not even philipj.

[07:09:05.0000] <philipj>
annevk: I get payed to point out misplaced commas and whitespace, just like you :)

[07:09:16.0000] <Ms2ger>
Glitch in the payroll, probably

[07:09:21.0000] <philipj>
I won't survive the AI revolution

[07:32:26.0000] <Ms2ger>
Does "frozen" mean anything special in https://html.spec.whatwg.org/multipage/semantics.html#frozen-base-url ?

[07:38:19.0000] <darobin>
it means you have to let it go

[07:39:39.0000] <Ms2ger>
Sounds like someone in this room has a kid

[07:50:19.0000] <annevk>
Ms2ger: I don't think so

[07:50:42.0000] <annevk>
Ms2ger: that probably needs to be reworded once we define base URL as a concept of Document

[08:09:22.0000] <annevk>
MikeSmith: can I get editbugs for w3c/webappsec on GitHub?

[09:22:29.0000] <MikeSmith>
botie, inform annevk don.

[09:22:29.0000] <botie>
will do

[09:44:46.0000] <botie>
annevk, at 2015-07-07 16:22 UTC, MikeSmith said: don.

[12:21:45.0000] <tdhsmith>
Hi all! I've got a minor DOM spec question -

[12:21:48.0000] <tdhsmith>
Is there a particular reason EventTargets don't have a getEventListeners method?  Are event listeners consider a (somewhat) private list?

[12:22:16.0000] <tdhsmith>
I see that Firebug and Chrome dev tools have a method for it...

[12:31:21.0000] <Ms2ger>
tdhsmith, "you shouldn't need to"? :)

[12:34:41.0000] <jgraham>
tdhsmith: Being able to inspect that kind of thing is the enemy of modularity

[14:06:06.0000] <terinjokes>
i've forgotten again, what's the difference between prefetch (from resource hints) and preload?

[14:11:11.0000] <tdhsmith>
Well my use case is that I'm building a library to collect statistics on how different sites use events.

[14:11:16.0000] <tdhsmith>
I'll admit it's quite a nonstandard use case, but right now the preferred approach is to override addEventListener before the other libraries run, which feels terribly unclean :/

[14:12:41.0000] <tdhsmith>
I'll go read the past discussions about EventListenerList when I get a chance. I can definitely respect that it might not be something for the spec to address.

[14:28:04.0000] <TabAtkins>
tdhsmith: That is indeed the right way to do this.  As Ms2ger and jgraham said, you generally don't need to, and most attempts at doing so are really terrible ideas that are good to prevent.  Making it a bit harder by requiring you to install an interceptor is a good thing.


2015-07-08
[01:38:46.0000] <howdoi>
is there a way to distinguish proxy object vs normal ones?

[02:49:53.0000] <Ms2ger>
/me wonders what the Hotlist-Interop label in chromium's issue tracker is for

[03:10:00.0000] <philipj>
Ms2ger: https://critic.hoppipolla.co.uk/r/5488 is for you :)

[03:11:20.0000] <Ms2ger>
Thanks!

[03:51:01.0000] <MikeSmith>
beverloo: thanks for the clarification. figured I had to be missing something :)

[03:51:18.0000] <beverloo>
we were quite bummed when we found out :(

[03:52:09.0000] <beverloo>
eventually we'll get icons on buttons as well :) for now, however, buttons would be a grand start. People could try to fiddle around with emoji instead.

[04:03:37.0000] <MikeSmith>
beverloo: yeah I guess we got a ways to go still on notifications behavior & features

[05:24:46.0000] <Ms2ger>
philipj, did the ChildNode parts, will look at the ParentNode parts in a bit

[05:27:31.0000] <philipj>
yay Ms2ger!

[05:28:22.0000] <philipj>
paritosh-in: have you used Critic before? You can just push changes to your pull request on GitHub to update https://critic.hoppipolla.co.uk/r/5488

[05:42:04.0000] <paritosh-in>
philipj: Ah, I haven't used it  before..

[05:46:58.0000] <Ms2ger>
paritosh-in, just don't force-push before we're ready to merge and all should be fine :)

[05:47:55.0000] <MikeSmith>
or rebase

[05:48:25.0000] <Ms2ger>
Rebase implies force push, but indeed

[06:49:58.0000] <paritosh-in>
Ms2ger: I updated the pull request

[06:50:04.0000] <Ms2ger>
Thank you

[07:17:48.0000] <Krinkle>
Hm.. does fetch() not have a way to know whether a request failed to foreign domains?

[07:18:12.0000] <Krinkle>
it seems that fetch(.., {mode: 'no-cors'}) yields the same for a 200 OK as a 404 not found

[07:20:23.0000] <Krinkle>
new Image() does expose onload/onerror;

[07:27:43.0000] <Ms2ger>
paritosh-in, reviewed more :)

[07:53:40.0000] <Ms2ger>
Should we pull https://github.com/Ygg01/xml5_draft into whatwg already?

[07:57:18.0000] <wanderview>
Krinkle: I believe opaque responses (mode:no-cors) hide all data by design... annevk (not here) is probably the person to ask for more details

[08:10:13.0000] <Krinkle>
wanderview: Yeah, I was hoping to get a boolean status out of it at least but no luck

[08:10:20.0000] <Krinkle>
e.g. promise reject

[08:10:28.0000] <Krinkle>
but it always fulfills and always with the same information

[08:10:33.0000] <Krinkle>
which is per the fetch() spec for no-cors

[08:10:35.0000] <Krinkle>
so that makes sense

[08:42:27.0000] <wanderview>
Krinkle: I think there are security concerns about leaking cross-origin info when CORS is not used... I don't really understand them all

[09:58:51.0000] <TabAtkins>
howdoi: Intentionally, no.

[09:58:56.0000] <TabAtkins>
That's the point of proxies.


2015-07-09
[00:19:13.0000] <paritosh-in>
Ms2ger: can I do git rebase -i?

[00:24:57.0000] <Ms2ger>
paritosh-in, yep

[06:21:13.0000] <annevk>
Ms2ger: I guess we can move the XML5 thing if Servo is actually committing

[06:21:42.0000] <annevk>
Ms2ger: well, and I guess we should discuss with the main maintainer, wouldn't want any disagreement

[06:57:05.0000] <annevk>
Krinkle_: that you can figure out things a bit for <img> (which is more related to decoding than HTTP state afaik) shouldn't mean that you can figure it out generically

[07:08:41.0000] <Krinkle>
annevk: yeah, I guess if we coudl go back and change it, we'd remove that exposure from Image as well

[07:11:41.0000] <annevk>
oh yes

[07:11:47.0000] <annevk>
CORS all the things

[07:14:06.0000] <Krinkle>
annevk: I forgot the use I wanted it for -_-

[07:14:12.0000] <Krinkle>
but now I can only think of anti-use cases

[07:14:24.0000] <Krinkle>
e.g. rest APIs that communitate success with http status code

[07:14:31.0000] <Krinkle>
and try different urls until you get it right

[07:15:13.0000] <Krinkle>
I guess that's still do-able with Image or just server-side …

[07:15:42.0000] <Krinkle>
unless the attack relies on it re-using the session but then 1) don't use session cookies in your api, 2) fetch() doesn't send cookies for forgeign domains

[08:23:29.0000] <annevk>
fetch() can send cookies

[11:26:49.0000] <TabAtkins>
annevk: If you start doing anything for XML5, please also talk with Dominic Cooney from our side.


2015-07-10
[18:43:46.0000] <jack_>
is anybody here ?

[18:46:06.0000] <gsnedders>
there are likely people around

[18:46:19.0000] <gsnedders>
you're probably best off asking and lurking around till someone answers

[18:46:53.0000] <jack_>
I need to ask something on HTML DOCTYPE.

[18:49:57.0000] <gsnedders>
just ask it.

[18:50:34.0000] <jack_>
okay! so here is my question...

[18:51:20.0000] <jack_>
why we use exclamation mark (!) in DOCTYPE declaration ?

[18:51:32.0000] <gsnedders>
Oh. Now that is historical!

[18:51:44.0000] <gsnedders>
Short version: because SGML did.

[18:52:11.0000] <jack_>
and long version ?

[18:53:07.0000] <gsnedders>
Well, SGML will have to disambiguate it from a start tag.

[18:53:53.0000] <gsnedders>
*will have ahd

[18:53:57.0000] <gsnedders>
**will have had

[18:54:24.0000] <gsnedders>
From memory (my copy of the SGML spec is hundreds of miles away!), SGML doesn't disallow any element names.

[18:54:41.0000] <jack_>
and one more is, why only angle brackets <> is used, and not square bracket or curly bracket ?

[18:55:57.0000] <gsnedders>
As opposed to using square brackets or curly brackets for DOCTYPE and CDATA sections and the like?

[19:11:02.0000] <jack_>
( ) this can also be used why only <> brackets in HTML?

[19:15:22.0000] <gsnedders>
You'd have to ask timbl that. Probably because he was going for something: a) simple; b) resembled SGML (in its default settings).

[19:22:18.0000] <jack_>
can anyone provide a best link for elaboration on SGML, think this as i am going to or want to learn SGML.

[19:34:04.0000] <jack__>
can anyone provide a best link for elaboration on SGML, think this as i am going to or want to learn SGML.

[19:35:15.0000] <Domenic>
google or wikipedia are likely the way to go for that

[19:37:36.0000] <jack__>
Its just providing me the information. I want to learn the SGML code or GML code. I want to know why only angle brackets are used and why not square or curly bracket.

[19:47:40.0000] <Domenic>
Again, I think Google or Wikipedia will be your best guide there.

[19:48:03.0000] <Domenic>
None of us is really an expert on decades-old technological ancestors of our current technology, I don't think

[23:27:54.0000] <annevk>
Hixie and zcorpan prolly are somewhat experts in SGML stuff

[23:28:32.0000] <annevk>
Hixie once famously convinced browsers to implement SGML-style comments

[00:43:28.0000] <Ms2ger>
-moz-prefixed gradients are dead \o/

[07:22:10.0000] <calvaris>
Domenic, tyoshino: where's Streams API implemented? V8 or Chromium?

[08:11:44.0000] <Domenic>
calvaris: Blink. There are plans to make it a V8 extra,  but it would still be living in the Blink repo.

[14:37:29.0000] <captain_>
is whatwg under control of google?

[14:37:48.0000] <boogyman>
no

[14:39:42.0000] <smaug____>
captain_: https://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F

[14:43:06.0000] <captain_>
wikipedia said there is only one decision maker

[15:27:13.0000] <smaug____>
captain_: wikipedia is then wrong

[15:27:58.0000] <smaug____>
wikipedia is wrong

[15:28:17.0000] <smaug____>
annevk sure is editing several whatwg specs

[16:07:16.0000] <Domenic>
Normally I find editing Wikipedia to be an exercise in frustration but I wonder if it's worth updating https://en.wikipedia.org/wiki/WHATWG#Specifications

[16:17:00.0000] <TabAtkins>
Ms2ger: Yay!

[16:37:53.0000] <jgraham>
That wikipedia page is all kinds of wrong


2015-07-11
[17:44:21.0000] <zewt>
ffff, need to figure out a generic greasemonkey script to make pages think everything is on screen

[17:44:44.0000] <zewt>
so sick of scrolling lists of results and having to scroll a little and then wait for images to load because of braindamaged mobile optimizations applied to desktop

[18:07:16.0000] <TabAtkins>
zewt: bet they poll scrollTop, so you're probably screwed

[11:00:03.0000] <Domenic>
annevk_: the same Event object is shared by all listener invocations, currently?

[11:10:42.0000] <annevk_>
Domenic: yes

[11:11:25.0000] <annevk>
Domenic: basically you iterate over the listeners for each node in the path and invoke them passing the object

[11:11:36.0000] <annevk>
Domenic: which should be pretty clear from the dispatch algorithm

[11:12:57.0000] <Domenic>
annevk: yeah, that was what I thought, but I hadn't taken the time to detangle the differences between e.g. conceptual "event" and Event objects, and a few other such things

[11:13:37.0000] <annevk>
Domenic: I guess there shouldn't be a conceptual event, should just be an alias for "Event object", if anything

[11:14:06.0000] <annevk>
Domenic: yeah, that language is a bit dated :-/

[11:14:34.0000] <annevk>
Domenic: mostly waiting for IDL to get internal slots to clean that up...

[11:15:11.0000] <Domenic>
Hmm you can call e.preventDefault() later, right? E.g. setTimeout(function () { e.preventDefault(); }, 100)? Or maybe not...

[11:15:34.0000] <Domenic>
preventDefault is such a strange name in the modern way of thinking :-/

[11:18:19.0000] <annevk>
Not quite sure what they were thinking originally

[11:18:29.0000] <annevk>
Domenic: no, all listeners are called in a single tick

[11:18:40.0000] <Domenic>
annevk: yeah, I guess it could change e.defaultPrevented, but not much else.

[11:18:55.0000] <annevk>
should maybe guard it with the dispatch flag...

[11:18:57.0000] <annevk>
meh

[11:19:10.0000] <Domenic>
email sent

[11:19:15.0000] <annevk>
ta


2015-07-12
[19:58:28.0000] <MikeSmith>
binary JSON

[20:06:28.0000] <gsnedders>
MikeSmith: I don't even want to ask why you uttered those words

[20:08:44.0000] <MikeSmith>
heh

[20:09:34.0000] <MikeSmith>
gsnedders: by uttering them I see have accidentally summoned binary JSON into actual existence

[20:11:39.0000] <gsnedders>
Fuck.

[20:17:28.0000] <MikeSmith>
well it's just a dumb name choice

[20:17:48.0000] <MikeSmith>
it doesn't really have anything to do with JSON

[23:42:33.0000] <annevk>
philipj: I don't really follow https://github.com/RByers/EventListenerOptions/issues/2#issuecomment-120667412

[00:49:06.0000] <Ms2ger>
annevk, around?

[00:57:52.0000] <annevk>
Ms2ger: sortof

[00:58:00.0000] <annevk>
Ms2ger: about to go hiking

[00:58:42.0000] <Ms2ger>
annevk, the DOM change you emailed about didn't really seem related to the thing I was talking about, or do I just not see the connection?

[00:59:13.0000] <annevk>
Ms2ger: the commit message was wrong

[00:59:37.0000] <annevk>
Ms2ger: but if you look at step 7 of concept-range-insert it should no longer set parent

[00:59:51.0000] <Ms2ger>
Oh, more changes

[00:59:59.0000] <Ms2ger>
/me should learn to continue reading

[01:00:12.0000] <Ms2ger>
Alright, thanks :)

[10:32:05.0000] <annevk>
http://furbo.org/2015/07/09/i-left-my-system-fonts-in-san-francisco/

[10:52:16.0000] <annevk>
If we are going to have a concept "user-interface window", should the property be called "uiWindow"?

[10:53:17.0000] <annevk>
Alternative, how would you name a reference to a global object whose associated browsing context is responsible for showing dialogs and security UI (e.g. address bar warnings)?

[10:53:28.0000] <annevk>
Alternatively*

[10:57:24.0000] <tantek>
what windows aren’t user-interface?

[10:59:14.0000] <annevk>
Yeah, maybe just "window" is enough

[11:01:43.0000] <annevk>
Well, only top-level browsing contexts can show mixed content warnings

[11:01:49.0000] <annevk>
That's a difference of sorts

[11:02:07.0000] <annevk>
Which I hadn't thought through enough so I guess I can't specify this yet

[11:02:51.0000] <tantek>
I’ll just keep asking naive questions

[11:03:05.0000] <annevk>
Context is https://github.com/whatwg/fetch/issues/70 fwiw

[11:03:35.0000] <annevk>
Trying to get the network stack to behave consistently across all types of workers and windows is somewhat involved

[11:22:46.0000] <annevk>
JakeA: still lacking a reply to https://github.com/whatwg/fetch/issues/66#issuecomment-118638144

[11:23:09.0000] <annevk>
I wish GitHub had needsinfo

[11:37:39.0000] <JakeA>
annevk: thanks for the nudge, will pick this up tomorrow afternoon if I'm laptop-capable


2015-07-13
[18:33:32.0000] <Domenic>
annevk: I sometimes use the assign feature as a sort of needsinfo, but it's meh

[19:36:39.0000] <MikeSmith>
botie, inform beverloo A comment from you at https://github.com/whatwg/notifications/issues/46 would be welcome.

[19:36:39.0000] <botie>
will do

[23:19:06.0000] <annevk>
Hixie: can we raise the cc limit for the WHATWG list?

[23:19:14.0000] <annevk>
Hixie: I keep hitting the limit

[23:22:39.0000] <MikeSmith>
annevk: did you see https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0099.html (Testing W3C's HTTPS setup)?

[23:22:53.0000] <annevk>
MikeSmith: did

[23:22:56.0000] <MikeSmith>
k

[23:23:03.0000] <annevk>
MikeSmith: but didn't really want to modify my setup

[23:23:09.0000] <MikeSmith>
ah OK

[23:24:32.0000] <MikeSmith>
well I've been trying it for a while and found a few problems (mostly just redirect loops) and systeam has fixed them all quickly

[23:24:36.0000] <MikeSmith>
so, progress

[23:26:04.0000] <MikeSmith>
but I've not been checking very carefully yet for mixed-content problems (to see if the Content-Security-Policy: upgrade-insecure-requests header is working as expected)

[23:34:45.0000] <annevk>
That only works in Chrome I think

[02:01:48.0000] <annevk>
philipj++ for editing help with Fullscreen

[02:02:07.0000] <annevk>
"fullscreen element" as concept refactoring is simplifying a ton of stuff

[02:02:16.0000] <philipj>
:)

[02:02:42.0000] <philipj>
let me know when it's settled down and I'll take another pass

[02:08:35.0000] <annevk>
philipj: do you know why collect ancestors looks top layers with only a single element?

[02:08:58.0000] <annevk>
philipj: should that also change to just looking for ancestor documents with a non-null fullscreen element?

[02:17:34.0000] <philipj>
annevk: yeah, I'm not sure why it's like that, what did it say before the top layer refactoring?

[02:17:48.0000] <annevk>
philipj: before it says fullscreen element stack with one element

[02:18:25.0000] <philipj>
oh, so I suppose the equivalent would be documents where the top layer stack has only on element with the fullscreen flag?

[02:18:26.0000] <annevk>
philipj: the top layer thing made it worse, it should just say single element that has its fullscreen flag set I suppose

[02:18:45.0000] <annevk>
philipj: yeah, changing it to that

[02:18:47.0000] <philipj>
if I'm not mistaken, this is all about exiting multiple levels of iframes when appropriate

[02:18:59.0000] <annevk>
philipj: yeah, was just thinking that too

[02:19:01.0000] <annevk>
ta

[02:19:16.0000] <philipj>
np

[02:34:14.0000] <philipj>
annevk: the note "HTML defines the exact conditions under which the fullscreen enabled flag ..." should probably be moved up one step

[02:36:24.0000] <annevk>
yes

[03:13:00.0000] <Ms2ger>
!summon TabAtkins

[03:52:33.0000] <philipj>
annevk: I've gone through the whole diff of recent changes and everything looks good now except for the open issues

[03:53:00.0000] <philipj>
probably would find more bugs if implementing though :)

[03:54:52.0000] <Ms2ger>
So go forth and implement :)

[04:42:22.0000] <MikeSmith>
annevk: CSP upgrade-insecure-requests just landed in gecko trunk, right?

[05:26:52.0000] <botie>
beverloo, at 2015-07-13 02:36 UTC, MikeSmith said: A comment from you at https://github.com/whatwg/notifications/issues/46 would be welcome.

[05:27:33.0000] <MikeSmith>
beverloo: I see you already commented there in the time since I left that message for you originally

[05:29:57.0000] <beverloo>
MikeSmith, no problem :) Thanks for pinging!

[05:33:02.0000] <MikeSmith>
beverloo: thanks for you comments and info

[06:11:55.0000] <TabAtkins>
Ms2ger: pong

[06:12:45.0000] <Ms2ger>
TabAtkins, a question about selectors, if you have a moment

[06:13:11.0000] <TabAtkins>
That's why I ponged

[06:14:21.0000] <Ms2ger>
Should :first-child etc. match an element a. without a parent node; b. whose parent is a Document; c. whose parent is a DocumentFragment; d. whose parent is an Element

[06:14:42.0000] <Ms2ger>
d. is obviously "yes", but I have no idea about the others

[06:14:56.0000] <Ms2ger>
Especially since selectors-3 and -4 seem to disagree

[06:15:44.0000] <TabAtkins>
S4 has the right answer. Let me review real quick.

[06:17:47.0000] <TabAtkins>
Yeah, :first-child/etc only care about relative position among siblings. Parent (or lack of) doesn't matter.

[06:19:16.0000] <Ms2ger>
How would you feel about adding a note near the definition or to the Changes section to point out the change is intentional?

[06:19:43.0000] <TabAtkins>
That's fine with me. Send email, as I won't be into the office for several hours yet?

[06:20:50.0000] <Ms2ger>
Sure

[06:37:59.0000] <Ms2ger>
Oh, I was going to cc the list

[06:38:00.0000] <Ms2ger>
Eh

[07:23:16.0000] <annevk>
MikeSmith: seems like it, got an email earlier anyway

[07:51:03.0000] <annevk>
JakeA: regarding no-cors CSS, https://bugzilla.mozilla.org/show_bug.cgi?id=1180145#c3 is our current thinking

[07:51:25.0000] <annevk>
JakeA: well, I guess it's mine, but I think the security people agree

[08:02:19.0000] <webzen>
hi

[08:03:16.0000] <webzen>
Can anyone give me some info on how es6 modules will be built and assembled on es6 browsers without using browserify or such ?

[08:04:07.0000] <webzen>
high level

[08:04:57.0000] <annevk>
webzen: there's an idea for <script type=module src=module.js>

[08:05:22.0000] <annevk>
webzen: https://whatwg.github.io/loader/ and its repo have some of the details for an even bigger plan

[08:06:02.0000] <webzen>
i tried to read that already but it was too low level.  So with main.js containing   import module1 from "./imports/module1";

[08:06:12.0000] <webzen>
how would the client get to the files on the server

[08:06:24.0000] <webzen>
to traverse the tree

[08:06:28.0000] <webzen>
of dependencies

[08:07:24.0000] <annevk>
client being?

[08:07:35.0000] <ondras>
well by using a regular http request that is normally used to fetch scripts

[08:07:42.0000] <webzen>
client being a es6 browser in the future.  and i start with <script src="build/js/main.js"></script>

[08:07:57.0000] <webzen>
but main.js only has  import module1 from "./imports/module1";

[08:08:01.0000] <ondras>
right. its dependencies will be fetched, analyzed, their dependencies fetched, analyzed, ....

[08:08:14.0000] <ondras>
and once the whole tree is statically analyzed, the code is finally run

[08:08:19.0000] <annevk>
it's not exactly defined how the translation happens and whether from "..." is a URL or some identifier

[08:08:21.0000] <webzen>
so the es6 browsers will make more requests ?

[08:08:43.0000] <webzen>
currently i have all my js in one file to reduce requests

[08:08:43.0000] <ondras>
if you serve your code in X files, X requests will be made

[08:08:54.0000] <webzen>
won't that be expensive ?

[08:08:55.0000] <annevk>
yeah, but not with HTTP/2

[08:09:05.0000] <ondras>
also you can pack your multiple ES6 modules into one

[08:09:12.0000] <annevk>
ondras: not anymore

[08:09:23.0000] <ondras>
annevk: I mean the System.register API

[08:09:24.0000] <annevk>
ondras: there's no syntax for inline modules

[08:09:30.0000] <ondras>
babel --modules=system or somth

[08:09:44.0000] <webzen>
ondras: i'm saying without babel

[08:09:49.0000] <ondras>
okay

[08:09:49.0000] <webzen>
in es6 browsers

[08:09:53.0000] <ondras>
http2 then

[08:09:56.0000] <ondras>
or multiple requests

[08:10:46.0000] <webzen>
is HTTP/2 in current browsers or is that future thing

[08:10:59.0000] <ondras>
http://caniuse.com/#feat=http2

[08:11:29.0000] <webzen>
so it's already in the current browsers

[08:13:13.0000] <webzen>
annevk: so are there any es6 browsers with this loader yet ?

[08:13:26.0000] <webzen>
thanks ondras

[08:13:34.0000] <annevk>
nope

[08:14:08.0000] <annevk>
I've been thinking about poking at it, but haven't made the time yet

[08:14:23.0000] <webzen>
so currently i'm using babel but in the future i'll just be able to use the es6 browsers and they will handle assembling the modules

[08:14:31.0000] <webzen>
?

[08:14:56.0000] <webzen>
or is my thinking wrong

[08:15:22.0000] <annevk>
sounds about right, you might need some tweaks here and there I guess, depends a bit on the final details

[08:15:41.0000] <webzen>
i just don't want to write code that will fail in the future

[08:16:01.0000] <webzen>
since i'm going to be writing es6 code

[08:20:06.0000] <webzen>
so to be clear, in the future es6 browsers they will be able to run the dependency from the client side by making multiple calls to build the file before running it yes ?

[08:26:39.0000] <annevk>
TabAtkins: can you roll https://github.com/plinss/widlparser/commit/43f0d6be64741642dd8ea9f6847dfec0ad3afb14 into bikeshed?

[08:27:59.0000] <webzen>
annevk: can you please affirm or correct my statement please ?

[08:28:26.0000] <annevk>
webzen: it's not entirely clear to me what that statement means

[08:28:38.0000] <webzen>
meaning i won't need babel or such

[08:28:50.0000] <annevk>
webzen: well yes, that's the intent

[08:28:52.0000] <webzen>
the browsers will handle the module assembling

[08:29:01.0000] <annevk>
yup

[08:29:10.0000] <webzen>
ok thanks so much

[08:29:14.0000] <webzen>
that's very helpful

[08:29:32.0000] <annevk>
and in some future future the module can be some WebAssembly code

[08:29:43.0000] <webzen>
i'll be playing guitar then :-)

[08:30:01.0000] <webzen>
WebAssembly is a thing ?

[08:30:18.0000] <annevk>
it's a thing: https://github.com/WebAssembly

[08:30:23.0000] <webzen>
oh dear

[08:31:10.0000] <TabAtkins>
annevk: Will do so shortly.

[08:31:32.0000] <webzen>
so i'll be able to start over with WebAssembly and forget all I know :-)

[08:32:53.0000] <webzen>
thanks again !

[08:34:26.0000] <TabAtkins>
Well, you'll be able to start over with whatever languages compile into WebAssembly. You won't write it directly, any more than you write asm.JS directly.

[08:36:06.0000] <caitp>
so, is wasm supposed to have enough type info and static knowledge of the program available to eg. bypass expensive optimization processes at runtime?

[08:36:17.0000] <caitp>
it would be pretty cool if it just plugged into ionmonkey/tf right away

[08:37:10.0000] <caitp>
since i guess you'd hope clang would do the LICM and constant folding and operator reduction and etc

[08:38:01.0000] <JakeA>
annevk: is your analysis at https://github.com/whatwg/fetch/issues/66#issuecomment-118638144 how it works now, or how a solution could work

[08:38:17.0000] <JakeA>
annevk: is your analysis at https://github.com/whatwg/fetch/issues/66#issuecomment-118638144 how it works now, or how a solution could work?

[08:38:23.0000] <annevk>
caitp: we're planning on making use of IDL to bypass a bunch of IDL stuff

[08:39:03.0000] <annevk>
JakeA: 'we should just expose it as a "redirect" (new type of response, identical to opaque except for its type and exposure of url as that is identical to the request url)' and what follows is a proposal

[08:42:12.0000] <JakeA>
(sorry for the repeated message, got caught in the netsplit)

[08:42:33.0000] <JakeA>
annevk: "If you then get back an opaque response you know that a redirect happened." - that's not what happens now though

[08:42:50.0000] <JakeA>
You get a non-opaque response back for the final non-redirect resource

[08:43:18.0000] <JakeA>
Since fetch(event.request) changes the mode of the request

[08:45:09.0000] <annevk>
JakeA: no it doesn't?

[08:46:47.0000] <JakeA>
annevk: hmm, I'm getting confused then https://fetch.spec.whatwg.org/#request-class "If request's redirect mode is "manual", set it to "follow"."

[08:47:07.0000] <annevk>
JakeA: oh, changes the redirect mode?

[08:47:13.0000] <annevk>
JakeA: right, we'd stop doing that

[08:47:59.0000] <JakeA>
annevk: ah, yes, sorry wasn't specific enough. Yeah, that's why I was asking if that line was you clarifying the current behaviour or a proposed behaviour. It's the latter, got it

[08:48:36.0000] <annevk>
it's the proposed behavior for redirect mode "manual", still not super helpful since you don't actually know where the redirect will go, but at least a little bit

[09:10:10.0000] <TabAtkins>
caitp: wasm starts with asm.js, basically, just in a binary format.  It'll grow optimizations and features as it goes.

[09:25:55.0000] <annevk_>
TabAtkins: that bug is one of the reasons for migrating to GitHub, would be hard to WONTFIX

[09:26:17.0000] <TabAtkins>
Why is it hard?

[09:27:05.0000] <annevk>
TabAtkins: it'll just get reopened

[09:27:40.0000] <annevk>
TabAtkins: a11y concern does seem like something that needs addressing one way or another

[09:27:44.0000] <TabAtkins>
You can just... close it again.  What's special about Bugzilla that makes it reopenable?

[09:28:06.0000] <TabAtkins>
Yeah, have an open bug on Bikeshed for that.  Just need to modify the CSSWG and WHATWG stylesheets to handle it.

[09:28:17.0000] <TabAtkins>
(So they dont' double-generate "Warning", etc.

[09:28:18.0000] <TabAtkins>
)

[09:29:20.0000] <annevk>
TabAtkins: feel free to WONTFIX and see what happens

[09:29:35.0000] <TabAtkins>
I'm not responsibel for the spec, so shrug.

[09:29:52.0000] <annevk>
TabAtkins: I wonder who they think will fix that bug anyway, with berjon leaving the W3C

[09:30:14.0000] <annevk>
And also, berjon made a vague promise of only subsetting, not forking

[09:32:36.0000] <TabAtkins>
Worth the paper it wasn't printed on, obvs.

[09:33:05.0000] <jgraham>
Oh did darobin leave?

[09:33:18.0000] <TabAtkins>
Did, or will soon, I forget. Working... I forget where.

[09:33:21.0000] <TabAtkins>
Somewhere cool.

[09:33:27.0000] <annevk>
NYC

[09:33:38.0000] <TabAtkins>
Yeah, def NY, just forget what company.

[09:35:20.0000] <annevk>
https://twitter.com/robinberjon/status/616565633539571712

[09:38:09.0000] <jgraham>
Presumably the Watson and Crick photo is an example of using someone else's data to make your discovery ;)

[09:39:14.0000] <TabAtkins>
jgraham: Context?

[09:39:14.0000] <botie>
Context is https://github.com/validator/validator/issues/61

[09:39:32.0000] <TabAtkins>
That's... incorrect, botie.

[09:39:32.0000] <botie>
TabAtkins: i'm not following you...

[09:39:54.0000] <jgraham>
TabAtkins: http://www.standardanalytics.io/

[09:40:10.0000] <TabAtkins>
ah

[09:41:02.0000] <Ms2ger>
.io, of course

[09:46:19.0000] <annevk>
"JSON-LD and RDFa"

[10:58:35.0000] <izhak>
Hi, guys! How do I import svg file with filters into html for use in css ?

[11:05:30.0000] <TabAtkins>
izhak: Just point to them with url() as usual.

[11:05:40.0000] <TabAtkins>
They're just images.

[11:06:33.0000] <izhak>
TabAtkins: I'm trying this:      filter: url(./filters.svg#mtshadow);

[11:07:00.0000] <TabAtkins>
Oh, you're trying to get an SVG *filter* into CSS.

[11:07:39.0000] <TabAtkins>
Still, that's supposed to work, per spec.

[11:07:49.0000] <TabAtkins>
http://dev.w3.org/FXTF/filters-1/#typedef-url

[11:08:31.0000] <izhak>
TabAtkins: yes. And currently I'm working with a local files (file:///). In firefox 39 when I click to that url in firebugs css console, it opens the svg file with filters. But filters refuse to apply...

[11:09:35.0000] <TabAtkins>
Hm, per caniuse.com, that should work.

[11:10:13.0000] <TabAtkins>
It's possible you need to flip the layout.css.filters.enabled flag?

[11:11:36.0000] <izhak>
Actually svg filters work when I open for example this: http://bl.ocks.org/cpbotha/5200394

[11:13:40.0000] <TabAtkins>
Yes, that's creating an inline SVG element.

[11:14:12.0000] <wanderview>
JakeA: if disk space is running low and an origin has its storage purged... is there anything in SW spec or chrome impl to run the SW install event again?

[11:14:43.0000] <izhak>
TabAtkins: What I do is copy the external html for svg tag in this example (using firebug), paste it to filters.svg and then refer to it as I showed.

[11:15:10.0000] <izhak>
I apply it to rect element, and it just disappears.

[11:15:53.0000] <TabAtkins>
If you view the filters.svg file, do you see the rect with shadows?

[11:17:10.0000] <izhak>
oops.. firefox opens it like a xml file.. looks like I forgot to add xmlns and version

[11:17:52.0000] <TabAtkins>
You don't need version, just xmlns

[11:18:12.0000] <TabAtkins>
(We're hoping to remove that requirement.)

[11:18:20.0000] <tantek>
xmlns lol

[11:18:26.0000] <TabAtkins>
tantek: indeed

[11:18:48.0000] <izhak>
TabAtkins: great it works now, thank you:)

[11:19:17.0000] <TabAtkins>
np

[11:23:33.0000] <JakeA>
wanderview: I don't think so, wouldn't that just fill up space again?

[11:24:13.0000] <wanderview>
JakeA: the problem is if the SW thinks its still installed... but its Cache was deleted out from under it... it may not try to re-populate without another install event

[11:24:17.0000] <wanderview>
this may be a gecko problem, though

[11:31:41.0000] <TabAtkins>
annevk: I'm confused about your questions about "the font API" and "such a CSS resource".  Are you under the impression that Font Loading does something with CSS files?

[11:34:11.0000] <annevk>
TabAtkins: is that not where it gets the FontFace stuff from?

[11:34:24.0000] <TabAtkins>
Stylesheets create FontFace objects, yeah.

[11:34:43.0000] <annevk>
right, and no-cors stylesheets shouldn't have their FontFace objects exposed, most likely

[11:34:51.0000] <TabAtkins>
Ah... Hm.

[11:34:56.0000] <annevk>
because that violates SOP

[11:37:31.0000] <TabAtkins>
Yeah, I suppose so.  I'll open a thread on www-style notifying people, and make the change.

[11:42:08.0000] <TabAtkins>
What's the right term to link for "CORS-enabled"?

[11:43:17.0000] <Krinkle>
JakeA: Do you know what the expected behaviour is with SW caching with regards to quota? See my comment at https://phabricator.wikimedia.org/T66721#1350485 for context.

[11:44:34.0000] <JakeA>
wanderview: yeah, I don't think we should be dropping part of an origin's storage

[11:44:53.0000] <JakeA>
wanderview: if we drop the cache or IDB, we should drop the SW too

[11:45:10.0000] <wanderview>
JakeA: yea, we should treat the registration as part of the origin storage... right now we have it in a separate non-origin-specific db

[11:45:25.0000] <wanderview>
the scripts live in origin storage though

[11:45:44.0000] <JakeA>
Krinkle: the cache uses the same origin storage as idb

[11:46:16.0000] <TabAtkins>
Ugh, this makes things complicated.  I need to include them in the source, but flag them so they're invisible to any query methods that aren't called by a blessed caller.

[12:04:19.0000] <izhak>
Guys, is it possible to apply perspective transformation to a svg group?

[12:05:13.0000] <TabAtkins>
Yes, but iirc you need to use the transform property, not the transform attribute.  (3d transforms are part of CSS, and not accepted in the SVG attribute)

[12:07:49.0000] <izhak>
Cool, thanks!

[12:12:29.0000] <TabAtkins>
heycam|away: Just hitting you with an explicit ping, I just posted https://lists.w3.org/Archives/Public/www-style/2015Jul/0150.html about FontFace objects from a cors-tainted stylesheet.

[13:37:24.0000] <annevk>
TabAtkins: CORS-tainted is not a thing

[13:37:24.0000] <annevk>
TabAtkins: simplest would be to simply filter out those FontFace objects I think

[13:38:44.0000] <TabAtkins>
annevk: Not really. It means that, for example, calling document.fonts.load("some-font-in-the-co-sheet 10px") will confusingly return a promise for an empty array of fonts.

[13:38:53.0000] <TabAtkins>
Despite actually kicking off loads.

[13:39:18.0000] <annevk>
That would make it observable

[13:39:21.0000] <TabAtkins>
And I still need the ability for the impl to use these algos and receive the "real" set.

[13:39:31.0000] <TabAtkins>
Loading behavior is already trivially observable via timing channels.

[13:39:42.0000] <TabAtkins>
If you know the font name, you can test for loaded status.

[13:39:50.0000] <annevk>
How?

[13:40:09.0000] <TabAtkins>
...the same way you measure whether a font is loaded today?

[13:40:57.0000] <TabAtkins>
Create an inline element styled with the font you want to measure, and a font you already know has loaded as a fallback.  Poll its width; when it changes, the first font has loaded.

[13:41:25.0000] <annevk>
Ah yeah

[13:41:40.0000] <TabAtkins>
(Ideally your fallback is a constructed font with weird metrics, very tiny or very big, so it's impossible to confuse your algo if the first font is already loaded.)

[13:41:58.0000] <TabAtkins>
So exposing load status of fonts you know by name isn't a further leak.

[13:43:03.0000] <TabAtkins>
Exposing the number of fonts in a tainted stylesheet, and the load status of those mystery fonts, is somewhat more information than is available today, but I have a slightly more complex proposal that addresses that, too.  At worst, it only exposes whether the stylesheet contains *any* fonts, but I might be able to spec it such that that's plugged too.

[13:43:50.0000] <annevk>
Yeah, that proposal seemed okayish

[13:44:04.0000] <annevk>
Hopefully we can get bz to take a look

[13:44:06.0000] <TabAtkins>
Which? #2 in the email, or #3 in the next?

[13:44:17.0000] <annevk>
#3

[13:45:11.0000] <annevk>
Anyway, thanks for tackling this switfly

[13:45:18.0000] <TabAtkins>
np

[13:45:44.0000] <boogyman>
is there some reason why exposing loading/loaded fonts is an issue?

[13:45:44.0000] <TabAtkins>
And thanks for prompting me to do the refactor necessary to fix the dom Bikeshed error. ^_^

[13:45:52.0000] <annevk>
And reach out to bz somehow I guess, not sure who else would be good to review this

[13:45:54.0000] <TabAtkins>
boogyman: It's more information than is exposed today.

[13:46:05.0000] <TabAtkins>
annevk: Already pinged heycam, about to ping our internal people.

[13:46:15.0000] <TabAtkins>
Tho that's just font implementors, not security people.

[13:46:22.0000] <boogyman>
but is that extra info a bad thing? what can someone really do with it?

[13:47:45.0000] <TabAtkins>
who knows? That's why we limit cross-origin data in the first place.

[13:48:08.0000] <TabAtkins>
It's often difficult to construct specific attack scenarios until they happen, so a blanket prohibition is often warranted.

[13:48:29.0000] <boogyman>
ah, I missed the CORS mention

[13:51:05.0000] <annevk>
Indeed, it's the combinatory explosion thing why we need to keep SOP as tight as it is now

[13:51:21.0000] <annevk>
Even security groups such as WebAppSec seem eager to break it :-(

[13:58:21.0000] <roc>
:-)

[13:58:58.0000] <annevk>
roc: rebel

[14:00:02.0000] <annevk>
nn

[14:39:23.0000] <jgraham>
So… why can't I find where the spec says what to do when you try to navigate and end up with a network error of some sort?

[16:04:19.0000] <Domenic>
Can dispatching an event (from spec) throw an error?

[16:04:25.0000] <Domenic>
Probably not...

[16:15:05.0000] <smaug____>
Domenic: it can if the event is already being dispatched

[16:15:24.0000] <smaug____>
(or if the event isn't initialized )

[16:16:22.0000] <smaug____>
oh, perhaps "from spec" means, implementation dispatching events

[16:16:36.0000] <Domenic>
smaug____: OK, but author listeners throwing doesn't need to be handled by specs that do "dispatch event"

[16:21:48.0000] <caitp>
do multiple event listeners ever happen in the same turn?

[16:22:11.0000] <TabAtkins>
No.

[16:23:09.0000] <caitp>
just trying to think of a situation where it would matter if the authors listener threw

[16:24:08.0000] <Domenic>
Of course they do...

[16:24:18.0000] <Domenic>
dispatchEvent() will fire them all, for one

[16:24:40.0000] <Domenic>
And queuing a task to fire an event from some other spec will call all of them, certainly.

[16:25:14.0000] <Domenic>
Right, OK, there's a try { call listener } catch (e) { reportException(e); } in the spec. https://dom.spec.whatwg.org/#concept-event-listener-invoke

[16:29:15.0000] <caitp>
i dunno man, the web is too complicated. no idea how you can ever tell if some change might break something unless it's really obvious

[16:30:48.0000] <caitp>
even for less complicated systems, it's really hard to tell if anyone ever depends on some subtle thing that might change between versions


2015-07-14
[18:48:28.0000] <MikeSmith>
/me wonders if any HTML parser implementors/testers are around

[18:48:40.0000] <MikeSmith>
thinking about https://github.com/inikulin/parse5/issues/26#issuecomment-113298544

[18:49:10.0000] <MikeSmith>
I'm not sure what he means there about "if an html opening tags is found in the 'in body' insertion mode, its attributes should extend the attributes of the first html element. Doing this would basically buffer the whole document in memory."

[18:49:52.0000] <gsnedders>
I am?

[18:49:56.0000] <gsnedders>
/me looks

[18:50:37.0000] <MikeSmith>
gsnedders: I think I know now

[18:51:05.0000] <MikeSmith>
he means specfically the `html` element in the "in body" insertion mode

[18:51:07.0000] <MikeSmith>
https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inbody

[18:51:22.0000] <MikeSmith>
the "Otherwise, for each attribute on the token, check to see if the attribute is already present on the top element of the stack of open elements. If it is not, add the attribute and its corresponding value to that element." part

[18:51:27.0000] <MikeSmith>
that is nuts

[18:52:12.0000] <gsnedders>
yeah, html start tags do that

[18:52:17.0000] <MikeSmith>
ok

[18:52:21.0000] <MikeSmith>
so he seems right

[18:52:25.0000] <gsnedders>
yep

[18:52:46.0000] <MikeSmith>
well I mean, he's right that doing that requires buffering the whole document in memory

[18:52:53.0000] <MikeSmith>
unless I'm missing something

[18:53:12.0000] <MikeSmith>
I don't understand what he means by "A way to mitigate this could be to send provisional html tags"

[18:53:42.0000] <gsnedders>
idk, sounds like doing weird shit by special casing the html element

[18:53:48.0000] <MikeSmith>
yeah

[18:53:58.0000] <gsnedders>
like sending "here's the html element", "oh wait no here's more for the html element"

[18:54:36.0000] <gsnedders>
the only practical way to do SAX for HTML is to admit fatal errors

[18:54:42.0000] <gsnedders>
IMO

[18:54:42.0000] <MikeSmith>
really?

[18:54:45.0000] <MikeSmith>
ok

[18:54:53.0000] <MikeSmith>
that's the core of what I've been wondering

[18:55:00.0000] <gsnedders>
you can so easily end up having to buffer so much that I'm never convinced it's worth it

[18:55:03.0000] <gsnedders>
esp. with AAA

[18:55:09.0000] <MikeSmith>
yep

[18:55:11.0000] <MikeSmith>
sadly

[18:55:28.0000] <MikeSmith>
though I was hoping to hear you say otherwise

[18:55:54.0000] <gsnedders>
the requirement that you fatally error when you first hit a parse error or never means you can't do limited buffering based on allowing n tokens, really

[18:56:03.0000] <gsnedders>
at least while complying with the spec

[18:56:19.0000] <gsnedders>
though maybe that's a memory limitation and hence allowable?

[18:56:46.0000] <MikeSmith>
hmm yeah but that would be a lazy way out

[18:56:50.0000] <gsnedders>
AAA only requires buffering while the list of formatting elements is not empty, no?

[18:57:02.0000] <gsnedders>
but you must always buffer while the list is not empty, right?

[18:57:19.0000] <MikeSmith>
ah yeah

[18:57:38.0000] <gsnedders>
and you have to buffer all tables entirely

[18:57:51.0000] <gsnedders>
I mean for a fair few documents that's essentially buffering the whole document

[18:57:52.0000] <MikeSmith>
sure yeah that's certain

[18:58:01.0000] <gsnedders>
which people probably don't expect of a streaming parser

[18:58:15.0000] <MikeSmith>
true

[18:58:20.0000] <MikeSmith>
again, sadly

[18:58:32.0000] <gsnedders>
I think the only sensible way to do a streaming API is buffer everything or admit fatal errors, basically.

[18:59:34.0000] <MikeSmith>
yeah so I guess that's wahy Henri's SAX parser just either buffers the entire document or lets you opt into fatal-error-for-any-non-streaming-case

[19:00:16.0000] <MikeSmith>
gsnedders: if you have time please consider adding a comment at https://github.com/servo/html5ever/issues/149

[19:00:23.0000] <MikeSmith>
and/or talking to SimonSapin about it here

[19:00:44.0000] <gsnedders>
try reminding me in a few days

[19:00:47.0000] <MikeSmith>
hai

[19:01:32.0000] <MikeSmith>
well I'll make a comment right now on that issue and point to the logs here and ping you in the comment

[19:01:55.0000] <MikeSmith>
and remind you later if needed

[19:08:17.0000] <gsnedders>
kk

[00:36:29.0000] <annevk>
jgraham: that's not defined by HTML?

[01:07:10.0000] <SimonSapin>
Thanks for looking into it MikeSmith, gsnedders

[01:10:15.0000] <Ms2ger>
That didn't take long: https://bugzilla.mozilla.org/show_bug.cgi?id=1182775

[01:11:58.0000] <MikeSmith>
SimonSapin: well Ivan Nikulin (parse5 implementor) is still convinced it's feasible

[01:12:10.0000] <MikeSmith>
he just commented a couple minutes ago to say as much

[01:12:19.0000] <MikeSmith>
https://github.com/inikulin/parse5/issues/26#issuecomment-121160391

[01:12:29.0000] <MikeSmith>
I very much hope he's right

[01:12:48.0000] <MikeSmith>
gsnedders: shttps://github.com/inikulin/parse5/issues/26#issuecomment-121160391

[01:12:50.0000] <MikeSmith>
oofs

[01:12:54.0000] <MikeSmith>
gsnedders: https://github.com/inikulin/parse5/issues/26#issuecomment-121160391

[01:14:07.0000] <MikeSmith>
Ms2ger: that means gmail's using invalid linear-gradient syntax?

[01:14:13.0000] <annevk>
Maybe he's saying something else? The parser doesn't really have to buffer, but it definitely needs to plug into some DOM...

[01:14:24.0000] <annevk>
MikeSmith: we removed -moz- gradient syntax

[01:14:38.0000] <MikeSmith>
annevk: ah OK

[01:15:07.0000] <MikeSmith>
I guess breaking gmail is a good way to find out if people are paying attention

[01:15:23.0000] <MikeSmith>
annevk: streaming parse

[01:15:26.0000] <MikeSmith>
*parser

[01:15:29.0000] <annevk>
You can implement <table><p> "streaming" as long as the other side can deal with "you need to modify the tree"

[01:15:56.0000] <MikeSmith>
well how does the other side know that ahead of time?

[01:15:57.0000] <annevk>
If the other side throws away the tree it's not going to be the correct

[01:16:08.0000] <annevk>
You don't

[01:16:26.0000] <SimonSapin>
MikeSmith: I wonder if you and him are talking about the same thing. The initial message of inikulin/parse5#26 is about making the input of the tokenizer (bytes or text) be a stream instead of a single string/buffer. I was asking whether the *output* of the tree builder could be like SAX/StAX

[01:16:46.0000] <annevk>
Yeah, agreed, he's talking about something else

[01:16:58.0000] <MikeSmith>
ah

[01:17:02.0000] <MikeSmith>
yeah

[01:17:07.0000] <MikeSmith>
/me looks back

[01:17:21.0000] <SimonSapin>
What annevk said. That last comment also talks about modifying nodes that were already "emitted"

[01:17:23.0000] <annevk>
We've known since 2006 or so that a streaming HTML parser requires a different set of rules

[01:17:34.0000] <MikeSmith>
yeah I misunderstand what kind of streaming that issue was about

[01:17:49.0000] <annevk>
And Hixie has thought of specifying one for search engines, but it never became high enough priority

[01:18:09.0000] <MikeSmith>
annevk: sure (about streaming requiring different rules)

[01:18:35.0000] <SimonSapin>
annevk: different rules would give different results, right? Isn’t that an interop problem?

[01:19:11.0000] <annevk>
SimonSapin: yeah, of sorts

[01:19:25.0000] <MikeSmith>
ah I didn't know that's what you meant

[01:19:28.0000] <annevk>
SimonSapin: but you'd opt into that for the perf

[01:20:31.0000] <SimonSapin>
hum, ok

[01:20:44.0000] <annevk>
I mean that was the idea

[01:20:44.0000] <MikeSmith>
I think that's not true the rules need to be different. The different rule is that you either need to buffer the whole document, or you need to just fail on any markup cases that need non-streaming behavior

[01:21:21.0000] <MikeSmith>
Henri's buffered SAX parser is fully conforming

[01:21:34.0000] <annevk>
At the time anyway e.g. Google didn't modify some tree so would have some minor differences from browsers, a tradeoff they thought was worth it

[01:21:42.0000] <annevk>
(Google the search engine)

[01:22:05.0000] <annevk>
MikeSmith: if you buffer it's not really streaming imo

[01:22:44.0000] <annevk>
MikeSmith: buffer the whole document is akin to just building a tree

[01:23:51.0000] <SimonSapin>
MikeSmith: I’m ok with the conclusion: it’s only possible with tradeoffs that make it not worth it. (Either not-really-streaming or fatal errors.)

[01:24:32.0000] <MikeSmith>
SimonSapin: ok

[01:26:33.0000] <MikeSmith>
annevk: well the difference is you're not also building some tree/DOM-like thing from it (which among other things requires a lot more memory than just putting the source into memory)

[01:26:45.0000] <MikeSmith>
but I agree it's not real streaming

[01:28:28.0000] <SimonSapin>
And so far I’m only guessing what the original poster of https://github.com/servo/html5ever/issues/149 is trying to do

[01:28:32.0000] <annevk>
MikeSmith: well even if you buffer the whole document you'll still need to create some tree, no? To be able to modify it and place that <p> before <table>?

[01:29:24.0000] <MikeSmith>
annevk: yeah but it can just be a much smaller and simpler stack

[01:30:06.0000] <MikeSmith>
I think Henri's parser keeps a few different stacks for that and other things

[01:30:29.0000] <MikeSmith>
but it never builds a tree of the entire document, nor needs to

[01:30:53.0000] <MikeSmith>
it mostly just passes on the events

[01:31:59.0000] <MikeSmith>
well, or in the end that's all the SAX API exposes, just eventsーstartElement, endElement, etc.

[01:35:20.0000] <jgraham>
annevk: Well it seems like it almost is?

[01:35:43.0000] <annevk>
now you're making me look

[01:36:36.0000] <jgraham>
annevk: I mean if I have <iframe src="someting that causes a network error or CORS error"></iframe> I *think* you end up in https://html.spec.whatwg.org/#read-ua-inline

[01:37:13.0000] <jgraham>
But then it's entirely unclear what e.g. iframe.contentDocument should be

[01:37:51.0000] <annevk>
step 22 of navigate seems to leave a bunch of things up to the user agent

[01:38:26.0000] <annevk>
it includes network errors in "some sort of processing that will not affect the browsing context"

[01:39:17.0000] <annevk>
jgraham: so yeah, I guess I don't really know

[01:40:51.0000] <jgraham>
I don't see how network errors will "not affect the browsing context" given that the normal implementation is to navigate to an error page

[01:41:23.0000] <annevk>
agreed

[01:42:04.0000] <jgraham>
The context here is SW tests that try to check that a CORS-forbidden resource didn't load

[01:42:50.0000] <jgraham>
Do you agree that checking that the iframe either has a null contentDocument or has a contentDocument but the contents are not the contents of the resource that was expected to load is reasonable per-spec

[01:42:55.0000] <jgraham>
?

[01:42:58.0000] <annevk>
I'm not sure what to tell you. You know better than anyone that navigate is a mess...

[01:43:20.0000] <jgraham>
Well yes :)

[01:43:55.0000] <annevk>
Yeah, that seems reasonable, but I would prefer a "TODO" comment there that suggests further work is needed to narrow it down to one or the other

[01:44:44.0000] <jgraham>
Sure, I'll file a spec bug later today and we can link that

[02:37:14.0000] <JakeA>
annevk: What redirect mode is CSS fetched with? What is it about the CSS fetch that allows relative URLs to work after redirects?

[02:37:38.0000] <annevk>
JakeA: nothing

[02:38:28.0000] <JakeA>
annevk: as in, it's not defined, or it doesn't need to be defined?

[02:38:42.0000] <annevk>
JakeA: it is defined and changes the default if you use fetch()

[02:39:13.0000] <annevk>
JakeA: we discussed this about fetch() vs event.default()

[02:39:29.0000] <annevk>
It wasn't seen as a problem...

[02:39:42.0000] <JakeA>
I'm not saying it is

[02:39:50.0000] <JakeA>
Just trying to follow it through the fetch spec

[02:40:26.0000] <annevk>
<link rel=stylesheet href=/x> ends up with /x being the base URL, regardless of what fetch("/") actually results in

[02:40:36.0000] <annevk>
it's no different from <img src=/x>

[02:41:38.0000] <JakeA>
annevk: ahh I see, so a normal fetch updates locationURL, which the CSS uses as its base?

[02:42:05.0000] <annevk>
no, fetch() doesn't update the URL

[02:42:15.0000] <annevk>
actually, I'm not even sure how to parse that sentence

[02:42:18.0000] <annevk>
locationURL is not a thing

[02:43:05.0000] <JakeA>
"Let locationURL be the result of parsing location with request's current url."

[02:43:28.0000] <JakeA>
Ahh, but that's appended to the request's url list

[02:43:35.0000] <JakeA>
I guess it's that that CSS uses to get its base url?

[02:44:38.0000] <annevk>
Again, if the request from the page is for /x, /x is the base URL even though fetch("/x") may follow many redirects

[02:45:50.0000] <annevk>
The `locationURL` stuff is completely local to the fetch() happening in the service worker

[02:46:00.0000] <JakeA>
annevk: I'm not talking about fetch(), I'm talking about how the part of the spec that requests CSS sets the base url correctly.

[02:46:06.0000] <JakeA>
I'm talking about without a SW

[02:46:24.0000] <annevk>
I see

[02:47:18.0000] <annevk>
JakeA: basically step 10 of "main fetch"

[02:47:52.0000] <annevk>
JakeA: https://fetch.spec.whatwg.org/#concept-response-url is the URL eventually used

[02:48:26.0000] <JakeA>
annevk: gotcha, cheers

[02:49:22.0000] <annevk>
(That note has a type s/request/response/ which I'll fix.)

[02:49:24.0000] <annevk>
typo

[03:15:10.0000] <annevk>
JakeA: so are you still figuring out what the complete picture should be for redirects?

[03:15:25.0000] <annevk>
/me has nearly fixed https://github.com/whatwg/fetch/issues/70

[03:21:14.0000] <ondras>
hmh

[03:21:15.0000] <ondras>
https://github.com/ModuleLoader/es6-module-loader

[03:21:31.0000] <ondras>
is some kind of baseurl supported with the es6 module loader?

[03:21:44.0000] <ondras>
the docs are only relevant for the 0.16 branch, that is outdated

[03:22:00.0000] <ondras>
and the 0.17 does not support System.baseURL. Is this feature present in the spec?

[03:31:00.0000] <JakeA>
annevk: trying to :) I think between opaque redirects and useFinalUrl (or whatever it gets called) we probably don't need event.default() - but just running it through my head

[04:03:59.0000] <MikeSmith>
fyi I just now deployed a somewhat disruptive change to the production W3C validator

[04:04:38.0000] <MikeSmith>
if anybody notices that the sky seems to be falling as result please ping me

[04:05:40.0000] <MikeSmith>
e.g., rage in the twitter-sphere or wherever about it breaking somebody's thing

[04:06:59.0000] <MikeSmith>
the validator is serving at least 9-10 validation requests a second so I'd imagine it will get noticed pretty quickly

[04:21:47.0000] <JakeA>
annevk: how are you feeling about the security the opaque redirect? Does it need further review? I could try and find someone for that

[04:22:13.0000] <annevk>
JakeA: I'm pretty confident with my outline

[04:22:47.0000] <annevk>
JakeA: the only thing I'm less sure about is exposing "manual", but I guess I should just do it

[04:23:26.0000] <annevk>
As in, I wonder if it's a good enough term and such

[04:24:37.0000] <JakeA>
annevk: would a cross-origin manual-redirect fetch be a network failure?

[04:25:34.0000] <annevk>
That's also a good question

[04:25:52.0000] <JakeA>
I shouldn't be able to detect redirects from other origins, and the different type would reveal that

[04:26:05.0000] <annevk>
You can already detect them with CSP

[04:26:17.0000] <annevk>
And now also with fetch(url, {redirect:"error"})

[04:26:42.0000] <JakeA>
hah, didn't realise CSP exposes that

[04:26:47.0000] <JakeA>
that's kinda suprising

[04:27:04.0000] <annevk>
WebAppSec, despite the name, is not great at SOP

[04:27:25.0000] <annevk>
(or redirects)

[04:28:11.0000] <annevk>
JakeA: I guess the other question is whether request /a with a opaque redirect whose url is /test should work

[04:29:20.0000] <annevk>
Restricting them to only those navigation requests that can handle them in the first place seems kind of nice

[04:29:29.0000] <annevk>
And further reduces the complexity tax

[04:30:36.0000] <JakeA>
annevk: yeah, I agree with you on that

[04:31:55.0000] <annevk>
JakeA: I guess I'll add all these restrictions for now, same-URL, same-origin

[04:32:11.0000] <annevk>
JakeA: it will handle navigate

[04:32:16.0000] <annevk>
and then we can see from there

[04:33:22.0000] <JakeA>
annevk: Just to check we're talking about the same thing, where are you going to make it fail? fetch(url, {redirect: "manual"}) should be able to return an opaque redirect, but if the SW returns it & the request isn't a navigation request, it'll fail.

[04:33:30.0000] <JakeA>
Is that what you're thinking?

[04:33:58.0000] <annevk>
it would fail if url is not same-origin

[04:34:19.0000] <annevk>
and it would fail if the response's url field from the SW does not match url

[04:35:06.0000] <JakeA>
same-origin makes sense

[04:35:47.0000] <JakeA>
annevk: what badness does the URL check prevent?

[04:37:37.0000] <annevk>
It would prevent creating a new code path that doesn't exist today

[04:38:20.0000] <JakeA>
I guess we can always open it out later

[04:38:37.0000] <annevk>
If I navigate to "/x" and the SW returns a redirect whose url is "/y" (redirecting to "/z"), the UA would have to redirect from "/x" to "/z"

[04:39:07.0000] <JakeA>
Yep

[04:39:10.0000] <annevk>
And not hit "/y", which is likely problematic

[04:39:34.0000] <JakeA>
Some potential weirdness with relative urls there too

[04:39:43.0000] <annevk>
I don't know, maybe it's okay

[04:40:02.0000] <JakeA>
We already allow returning a redirect to anywhere

[04:41:01.0000] <annevk>
That is true, but user agent code around redirects is even more fragile than I thought, so I'm a bit worried

[04:44:09.0000] <annevk>
Perhaps the navigate restriction is enough for now. I can't really think of anything bad with that restriction plus the opaqueness

[04:44:30.0000] <annevk>
Other than potential impl issues, but impls can raise those separately

[05:58:10.0000] <MikeSmith>
annevk: btw looking further at Henri's SAX-API parser code, I realize I was talking out of my hat earlier

[05:58:20.0000] <MikeSmith>
as far as it not building a full tree

[05:58:30.0000] <MikeSmith>
https://github.com/validator/htmlparser/tree/master/src/nu/validator/saxtree

[05:59:05.0000] <MikeSmith>
it's even called "saxtree", which should have been a clue to me

[07:37:06.0000] <Ms2ger>
philipj, any news on https://code.google.com/p/chromium/issues/detail?id=310450 ?

[07:38:39.0000] <philipj>
Ms2ger: no, I haven't really made any attempt at all since I filed it

[07:38:50.0000] <philipj>
is it a site compat problem?

[07:39:12.0000] <philipj>
I presume you've also seen the discussion I and roc are having on the WHATWG mailing list?

[07:39:18.0000] <philipj>
somewhat related, at least

[07:39:42.0000] <Ms2ger>
No, I was just cleaning out old emails

[07:40:42.0000] <philipj>
OK, let me know if you're having trouble with that default in particular, that would be a reason to bump its priority over the other gazillion :)

[07:41:18.0000] <Ms2ger>
philipj, if you have a test in wpt, I can have some newcomer pick it up :)

[07:41:46.0000] <philipj>
Ms2ger: The problem with preload and wpt is that the spec just doesn't say much normative at all :/

[07:41:59.0000] <Ms2ger>
\o/

[07:42:28.0000] <philipj>
We wrote some pretty elaborate buffering tests for preload behavior for Presto, but there's just no justification for it in the spec, so they were removed during upstreaming

[07:42:59.0000] <philipj>
maybe we should have a "stuff we agree on even though the spec allows for differences" test suite :)

[07:43:35.0000] <Ms2ger>
I think that would make sense

[07:44:18.0000] <philipj>
maybe some way to mark tests as optional in wpt?

[07:44:30.0000] <Ms2ger>
jgraham, ^

[08:01:38.0000] <jgraham>
I guess? I mean I don't really like the idea of optional tests

[08:03:24.0000] <Ms2ger>
I generally think that more test coverage in CI is nice, even if there's disagreement about whether a FAIL is a failure

[08:07:19.0000] <gsnedders>
SimonSapin: FWIW, I think admitting fatal errors probably is useful for some uses (mostly when you're dealing with large corpora and trying to do analysis of it, and rejecting some inputs doesn't hurt too much)

[08:08:04.0000] <gsnedders>
philipj: are thy in t/core?

[08:08:11.0000] <gsnedders>
philipj: like, the dump of it?

[08:09:14.0000] <philipj>
gsnedders: yeah, the tests exist in public

[08:09:40.0000] <philipj>
they were even part of a wpt review that maybe I could dig up if you're very curious

[08:10:00.0000] <gsnedders>
nah, not really

[08:10:04.0000] <gsnedders>
:)

[08:10:39.0000] <philipj>
in any case, they are or have been somewhere in https://github.com/operasoftware/presto-testo/tree/master/core/standards/web-apps/media

[09:45:01.0000] <Ms2ger>
Any reason https://terinjokes.github.io/console-spec/ isn't on spec.whatwg.org?

[09:49:27.0000] <annevk>
Ms2ger: I guess it isn't quite ready yet

[09:54:57.0000] <annevk>
https://twitter.com/domenic/status/620998989144530944 still waiting for whatwggreen

[09:57:34.0000] <annevk>
terinjokes: <3 console spec logo

[09:59:39.0000] <giltayar>
Who's working on script type="module"?

[10:01:15.0000] <annevk>
giltayar: dherman is

[10:16:22.0000] <webzen>
hi

[10:16:22.0000] <botie>
what's up, webzen

[10:16:38.0000] <webzen>
i'm stuck http://laravel.io/bin/321ne

[10:16:42.0000] <webzen>
trying to bundle

[10:21:42.0000] <webzen>
please :-)

[10:30:41.0000] <annevk>
https://twitter.com/w3cmemes/status/621008028578349056 is pretty excellent trolling on several levels

[10:30:49.0000] <annevk>
kudos

[11:02:28.0000] <smaug____>
heh

[12:01:47.0000] <arno_>
Hi, I have a question about CanvasRenderingContext2d.putImageData

[12:01:53.0000] <arno_>
spec says that "Throws a NotSupportedError exception if any of the arguments are not finite."

[12:02:28.0000] <arno_>
https://developers.whatwg.org/the-canvas-element.html#pixel-manipulation

[12:02:55.0000] <arno_>
but idl spec says that "If x is NaN, +Infinity or −Infinity, then throw a TypeError." (when converting to double)

[12:03:04.0000] <arno_>
http://www.w3.org/TR/WebIDL/#idl-double

[12:03:37.0000] <arno_>
this seems conflicting to me. So I'm wondering if that's that a bug in the spec, or if did miss something?

[12:04:23.0000] <Domenic>
Hmm that sounds like a bug

[12:05:03.0000] <Domenic>
arno_: already fixed in latest spec https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-putimagedata

[12:05:10.0000] <Domenic>
sadly developers.whatwg.org is old :(

[12:06:09.0000] <arno_>
Domenic: I still see it

[12:06:16.0000] <arno_>
Throws a NotSupportedError exception if any of the arguments are not finite.

[12:06:23.0000] <arno_>
https://html.spec.whatwg.org/multipage/scripting.html#pixel-manipulation

[12:06:29.0000] <Domenic>
arno_: oh, that's in the non-normative description

[12:06:33.0000] <Domenic>
yeah i guess that's a bug

[12:06:43.0000] <Domenic>
mind filing it? should be able to just select the text and click something in the lower-riught

[12:07:39.0000] <arno_>
oh. It turns out it's already filled

[12:07:41.0000] <arno_>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28327

[12:07:50.0000] <arno_>
Domenic: thanks for the help

[12:09:00.0000] <Domenic>
Gosh, wouldn't it be nice if HTML was something you could pull request...

[13:03:18.0000] <wanderview>
Domenic: in chrome's implementation... does response.body.cancel() effectively cancel the backing fetch?

[13:03:28.0000] <Domenic>
wanderview: yep

[13:03:43.0000] <wanderview>
Domenic: do we need that cancelable promise thing for fetch then?

[13:03:54.0000] <Domenic>
wanderview: yes, if we want to cancel before headers arrive

[13:04:08.0000] <wanderview>
right

[13:04:15.0000] <wanderview>
ok

[13:54:50.0000] <jsbell>
Ms2ger: In wpt's FileAPI tests, there are assertions that e.g. "te(xt/plain" is not a valid type - https://github.com/w3c/web-platform-tests/blob/master/FileAPI/blob/Blob-slice.html#L165 -  do you know where that requirement comes from? Assertions fail in Gecko and Blink, doesn't match spec. (I can PR to fix, just wondering about the history)

[14:11:12.0000] <smaug____>
in chromium how does one reply to a message event in serviceworker?

[14:11:17.0000] <smaug____>
event.source seems to be null there

[14:15:45.0000] <Ms2ger>
jsbell, it used to say that at least

[14:16:09.0000] <Ms2ger>
jsbell, I'd be glad to see fixes to current spec

[14:24:24.0000] <jsbell>
Hrm, wonder if he meant "to align with spec" or "to align spec with tests"

[14:36:20.0000] <jgraham>
jsbell: I'm pretty sure he means "so that tests and spec and impementations all align"

[14:37:09.0000] <annevk_>
jsbell: step 5 https://w3c.github.io/FileAPI/#constructorBlob

[14:37:51.0000] <annevk>
I think it used to do an actual MIME type check... not sure why that got removed again

[14:38:02.0000] <jsbell>
yep

[14:38:12.0000] <annevk>
Implementers are so lazy when it comes to data types

[14:38:50.0000] <annevk>
Languages, MIME types, encoding labels, ...

[14:39:00.0000] <jsbell>
yep => those steps don't ensure it's a "parsable MIME type", just that anything non-ASCII => "", otherwise just lower-cased

[14:39:49.0000] <annevk>
that spec is a bit of a mess

[14:39:52.0000] <jsbell>
the 2012 version had a bit more verbiage but I think it was normatively the same

[14:45:11.0000] <annevk>
philipj: smaug____: https://github.com/whatwg/dom/issues/54

[14:55:31.0000] <smaug____>
hmm, maybe

[14:55:43.0000] <smaug____>
probably

[15:06:49.0000] <Domenic>
:D

[15:33:50.0000] <sicking>
Domenic: I suspect it'll be easier to add a subclass to Array that has .item(), than to try to deprecate .item() on an API-by-API basis

[15:34:00.0000] <Domenic>
sicking: fair enough, yeah

[15:34:09.0000] <sicking>
Domenic: i agree that it sucks though.

[15:34:37.0000] <sicking>
Domenic: i guess we could even try to add Array.prototype.item... that seems unlikely to work though

[15:36:08.0000] <Domenic>
sicking: yeah a subclass seems preferable to that. Although I imagine the writers of Web IDL binding code will not be as excited about another custom type :P

[15:36:30.0000] <sicking>
meh, I think that's the least of our problems

[15:37:06.0000] <Domenic>
I dunno, I got pretty strong pushback trying to make DOMException a custom type (like ES Errors) instead of a WebIDL-defined one.

[15:37:28.0000] <Domenic>
I guess the payoff is higher here

[15:37:30.0000] <sicking>
Other than the sadness of the confusion of having some Arrays with .item, and some without .item, Gecko's first problem would be that we don't support subclasses of natives yet

[15:37:59.0000] <Domenic>
I hear that's almost there...

[15:38:16.0000] <sicking>
yeah. I don't know what "almost" means though

[15:38:24.0000] <sicking>
but yeah, i've heard that too


2015-07-15
[19:08:12.0000] <MikeSmith>
Domenic: re: "Gosh, wouldn't it be nice if HTML was something you could pull request..." dunno if you've seen https://github.com/w3c/spork#editing yet but that's exactly the intent of it

[19:08:29.0000] <MikeSmith>
it's pretty nuts really, on several levels

[19:08:55.0000] <MikeSmith>
from the twisted mind of Robin Berjon

[19:09:49.0000] <MikeSmith>
example of a spork PR for a bug fix to the spec https://github.com/w3c/spork/commit/d5fd2371fc7142eca2a70050e88879ff1f0e90ea

[19:10:15.0000] <MikeSmith>
not for the faint of heart

[19:24:00.0000] <Domenic>
Yeah I'd rather figure out a way to get changes into the spec used by implementers though, not the fork.

[19:41:26.0000] <TabAtkins>
MikeSmith: That's... pretty fucked.

[19:44:29.0000] <MikeSmith>
yeah I guess it's also not such a wonderful thing that right now the process of trying to get changes into this spec doesn't use the collaboration mechanisms we're now commonly using for most other specs

[00:50:53.0000] <annevk>
philipj: so remove hierarchy restrictions on requestFullscreen()... Then file a bug on HTML to define the inert thing based on top layer? Do we then still need top layer algorithms? Or should I define the inert stuff in Fullscreen?

[01:22:31.0000] <annevk>
jochen__: if you have time to chat about referrer today that'd be great

[01:33:10.0000] <annevk>
jochen__: I summarized all the points I want to talk about here: https://github.com/whatwg/fetch/issues/80

[01:42:20.0000] <annevk>
mkwst: ^^

[01:43:19.0000] <mkwst>
sorry, scribing a TAG meeting, arguing with them about security this afternoon.

[01:43:26.0000] <mkwst>
you should talk to jochen__ though!

[01:43:33.0000] <mkwst>
otherwise, I'm back home tomorrow.

[01:43:53.0000] <annevk>
alright, sounds good, I got a pile of stuff we need to go through :-P

[02:02:53.0000] <annevk>
JakeA: type "opaqueredirect"?

[02:05:11.0000] <JakeA>
annevk: works for me. Would it be more consistent to hyphenate?

[02:05:38.0000] <annevk>
JakeA: not necessarily, e.g. "sharedworker"

[02:07:34.0000] <JakeA>
annevk: true

[02:09:22.0000] <annevk>
Hmm, filtered responses don't filter url list

[02:09:26.0000] <annevk>
That seems like a bug

[02:10:55.0000] <annevk>
MikeSmith: I guess "basic filtered response" -> "basic filtered-response"?

[02:11:13.0000] <annevk>
MikeSmith: but "filtered response" can remain as is when it is on its own?

[02:28:18.0000] <philipj>
annevk: maybe an "add to top layer" algorithm isn't needed for the inert stuff, but perhaps for sanity if a spec tries to add an element which is already in the top layer?

[02:30:29.0000] <annevk>
philipj: you mean for the "add, or move if already present" phrase?

[02:30:53.0000] <MikeSmith>
annevk: well in that case it can stay as "basic filtered response" I think, because I think it's clear in context because there it's clear that "basic" is modifying "filtered response" (again, some of this comes down to judgement calls)

[02:51:34.0000] <smaug____>
impossible to get github.io working :/

[02:52:25.0000] <philipj>
annevk: yes, exactly

[02:52:44.0000] <philipj>
unless HTML already says the very same thing and there is no problem

[03:02:21.0000] <annevk>
smaug____: what's the problem?

[03:02:54.0000] <annevk>
philipj: I'm happy to add add/remove abstractions while removing the hierarchical restrictions

[03:03:11.0000] <annevk>
philipj: I guess then someone needs to file a bug on HTML to do the remaining work around inertness

[03:03:35.0000] <philipj>
annevk: Sounds like a plan

[03:04:43.0000] <smaug____>
annevk: well, getting it to work, at least in Finland. for github folks http://smaug----.github.io/ seems to work, but not here in Finland.  That page should have been there since last night already

[03:05:05.0000] <smaug____>
(I'd just like to expose serviceworkerconsole via some https pages)

[03:05:34.0000] <smaug____>
(similar silly little thing for testing as what http://mozilla.pettay.fi/workerconsole/ is)

[03:07:10.0000] <annevk>
Interesting, https://smaug----.github.io/ doesn't work

[03:07:29.0000] <annevk>
That's probably another case of Gecko's overzealous domain checker

[03:07:36.0000] <annevk>
smaug____: I get "Nothing to see"

[03:07:41.0000] <smaug____>
that is ok then

[03:07:46.0000] <smaug____>
Nothing to see is the expected

[03:07:53.0000] <annevk>
(in Gecko I get a certificate error)

[03:07:54.0000] <smaug____>
I get,  "no server found"

[03:08:06.0000] <annevk>
(though only for the https version)

[03:09:24.0000] <smaug____>
so in theory https://smaug----.github.io/serviceworkerconsole/index.html might work.

[03:11:11.0000] <smaug____>
btw, I found serviceworker API overly complicated, and weird even for simple stuff like communication. One adds message listener to one object but uses postMessage on some other one.

[03:11:39.0000] <smaug____>
that is with about 15mins experience with SW API :)

[03:12:05.0000] <annevk>
smaug____: 404 in Chrome, cert error in Gecko

[03:12:09.0000] <smaug____>
fun

[03:12:20.0000] <smaug____>
oh well

[03:15:55.0000] <beverloo>
annevk, just to confirm, Notification.vibrate will expose the validated and normalized version of the pattern given in NotificationOptions, and will thus expose some of the UA-imposed limits (max length and max duration in the Vibration API)

[03:16:14.0000] <annevk>
yeah

[03:16:28.0000] <beverloo>
this is fine by me, but I don't want it to be an oversight :)

[03:16:47.0000] <beverloo>
as soon as FrozenArray is available in Chrome we'll ship it, hopefully Chrome 46

[03:21:58.0000] <annevk>
cool

[03:27:55.0000] <MikeSmith>
annevk: fyi https://bugzilla.mozilla.org/show_bug.cgi?id=1184049 SteveF_ reports that for Notifications in Firefox, Firefox doesn't cause them to be exposed/announced to AT users in a way that makes them accessible

[03:28:29.0000] <annevk>
:-/

[03:28:45.0000] <SteveF_>
marco found old bug he filed so moved over there https://bugzilla.mozilla.org/show_bug.cgi?id=1052776

[03:28:58.0000] <MikeSmith>
ah ok

[03:30:18.0000] <MikeSmith>
btw I think another use case for having notification sounds is something Leonie mentioned, which is that if she has several channels open in an app like Slack or Gitter, and somebody pings her and it creates a notification, she doesn't know which channel it's from

[03:31:27.0000] <MikeSmith>
but I guess if things worked correctly she should be able to navigate automatically from that notification to whatever document/window that generated it

[03:32:10.0000] <MikeSmith>
focus on the notification, hit enter, it should focus the tab it came from

[03:32:46.0000] <MikeSmith>
ah yea but the problem is one tab/document can be showing several different chat rooms/channels at once

[03:34:01.0000] <MikeSmith>
man, I see Marco filed that bug more than year ago

[03:34:17.0000] <MikeSmith>
oh, not quite but almost a year ago

[03:36:43.0000] <annevk>
I believe i18n kind of sucks for notifications across implementations too :-/

[03:36:50.0000] <MikeSmith>
yup

[03:37:08.0000] <MikeSmith>
things can only get better!

[03:38:29.0000] <annevk>
Yeah, but if you don't read windows-1252 or are blind or some such you're out of luck for the first five years of a new feature...

[03:39:35.0000] <annevk>
Have to hand it to Apple for getting those things right when they ship new products (at least that seems to be the general impression)

[03:42:36.0000] <Dumu>
Hello everyone, when I visit https://developers.whatwg.org with Firefox, it says it is in offline mode. But when I visit it with Chromium, it's fine.

[03:43:27.0000] <MikeSmith>
oh boy

[03:43:43.0000] <MikeSmith>
I wonder who decided it would be a good idea to use appache for that

[03:44:09.0000] <Dumu>
also ok with Opera

[03:45:09.0000] <MikeSmith>
Dumu: I'm not sure we still have an active maintainer for that version

[03:45:23.0000] <MikeSmith>
anybody remember who was maintaining it last?

[03:48:04.0000] <beverloo>
MikeSmith, annevk, fwiw, Sanghyun is looking at implementing the `sound` attribute for Chrome

[03:48:13.0000] <MikeSmith>
ah cool

[03:48:39.0000] <beverloo>
we're generally in favor, but figuring out reasonable limits will be interesting - don't want this to become a way of playing multi-minute audio tracks

[03:48:59.0000] <MikeSmith>
yup

[03:49:12.0000] <MikeSmith>
like window.name

[03:49:23.0000] <beverloo>
hah :)

[03:50:01.0000] <MikeSmith>
store you music collection in a notification.sound to share with others!

[03:50:49.0000] <MikeSmith>
Dumu: i'm still searching through logs to try to figure out who to ping about that doc

[03:50:50.0000] <annevk>
Dumu: developers.whatwg.org is not a recent version of HTML unfortunately

[03:50:50.0000] <beverloo>
before we supported Notification.data, developers were storing stuff in the hash part of the icon URL :/

[03:51:22.0000] <MikeSmith>
hah

[03:51:25.0000] <Dumu>
I didn't realise it was an out-of-date version

[03:51:32.0000] <annevk>
MikeSmith: pretty sure it's https://twitter.com/benschwarz

[03:52:15.0000] <MikeSmith>
annevk: It was but I thought recently somebody else had been building it

[03:52:23.0000] <MikeSmith>
anyway you're right it's old

[03:52:34.0000] <annevk>
Dumu: https://html.spec.whatwg.org/multipage/

[03:52:46.0000] <annevk>
I wish developers.whatwg.org listed a date somewhere

[03:53:00.0000] <MikeSmith>
Dumu: yeah you're best off just using the full https://html.spec.whatwg.org/multipage/

[03:53:22.0000] <Dumu>
cool, thanks for letting me know - I shall disseminate this

[04:27:24.0000] <annevk>
smaug____: https://bugzilla.mozilla.org/show_bug.cgi?id=1184059 if you care

[04:27:40.0000] <annevk>
smaug____: (about the cert error for your github.io thing which doesn't work in Finland anyway)

[04:28:18.0000] <annevk>
smaug____: can you access github.io through a VPN btw? Finland has a firewall of sorts?

[04:31:20.0000] <smaug____>
I can access https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html just fine

[04:31:45.0000] <smaug____>
annevk: interesting

[04:32:08.0000] <smaug____>
well, I can't access the http:// url either

[04:32:09.0000] <annevk>
smaug____: maybe your DNS provider is strict

[04:32:15.0000] <annevk>
smaug____: DNS resolver that is

[04:32:24.0000] <smaug____>
yup, could be

[04:32:32.0000] <annevk>
smaug____: perhaps if you use Google DNS or some such you could access it?

[04:32:41.0000] <smaug____>
not going to use google services

[04:32:49.0000] <smaug____>
but if there is something else

[04:32:50.0000] <annevk>
or OpenDNS

[04:33:15.0000] <annevk>
hmm

[04:35:25.0000] <smaug____>
hsivonen_: ping

[04:37:10.0000] <Ms2ger>
smaug____, on vacation, I think

[04:38:09.0000] <smaug____>
hmm, who else from Finland here...

[04:39:56.0000] <Ms2ger>
I guess poiru is in SF still

[04:40:25.0000] <smaug____>
it would be great it me trying to use github.io would reveal two bugs: one on operator side and one in Gecko

[04:40:52.0000] <smaug____>
s/it me/if me/

[06:09:03.0000] <jochen__>
annevk: around?

[06:09:40.0000] <annevk>
jochen__: yup

[06:09:49.0000] <jochen__>
you wanted to chat

[06:10:01.0000] <annevk>
jochen__: yeah, did you see the new fetch issue I wrote up?

[06:10:05.0000] <jochen__>
yes

[06:10:14.0000] <jochen__>
makes sense i guess

[06:10:36.0000] <jochen__>
i still need to chat with jww about suborigins and pushState but that seems like a separate issue

[06:10:42.0000] <annevk>
jochen__: it has one open question at the end, how the global referrer policy interacts with request's referrer policy (aka referrer="")

[06:11:03.0000] <jochen__>
do we really need a referrer attribute on anchors? :-/

[06:11:41.0000] <annevk>
jochen__: my understanding is that Yahoo! would like to set a global policy of "origin", but then use "unsafe-url" for some stuff they vetted in some way

[06:12:19.0000] <annevk>
jochen__: well, I'm not a big fan per se, but apparently some folks from Mozilla security are quite invested in it

[06:12:46.0000] <jochen__>
and by some you mean one

[06:12:58.0000] <jochen__>
and by invested you mean they implemented it and would rather not have their patch go wasted

[06:13:38.0000] <annevk>
well, I talked with at least three people the other day and they had invited more, but one of them has been doing the impl work I think

[06:13:50.0000] <jochen__>
in any case, i guess the only way this could work is that the referrer attribute just overrides the document's referrer policy when it creates a request

[06:14:15.0000] <jochen__>
i'd like to know what sid thinks of it

[06:14:18.0000] <jochen__>
he owns the core impl after all

[06:14:22.0000] <jochen__>
(in firefox)

[06:14:34.0000] <annevk>
right, it's not exactly hard, it just seems weird that an attribute could override a policy set through CSP

[06:14:43.0000] <jochen__>
yes

[06:14:52.0000] <jochen__>
but so does rel=noreferrer

[06:14:58.0000] <annevk>
well, that exposes less

[06:15:03.0000] <jochen__>
yeah

[06:15:16.0000] <annevk>
as I understand it the specific case Yahoo! is interested in is exposing more

[06:15:26.0000] <jochen__>
but you can also change the referrer policy to unsafe-url even though the csp said never

[06:15:33.0000] <jochen__>
(by inserting a fresh meta tag)

[06:15:40.0000] <annevk>
okay

[06:15:52.0000] <annevk>
so maybe referrer policy is a separate beast

[06:15:59.0000] <jochen__>
yes

[06:16:04.0000] <jochen__>
btw, we still lack feature detection

[06:16:12.0000] <jochen__>
that would actually be useful

[06:16:19.0000] <jochen__>
so sites wouldn't have to user-agent sniff

[06:16:28.0000] <annevk>
w("referrer" in document.createElement("a")) should work?

[06:16:29.0000] <jochen__>
but I don't know how to expose this in the platform

[06:16:54.0000] <jochen__>
when we have the referrer attribute, that's right

[06:17:00.0000] <jochen__>
it still doesn't tell you which policies the browser supports

[06:17:16.0000] <jochen__>
e.g. safari still only has the policies that adam and me defined in the whatwg wiki

[06:17:37.0000] <annevk>
jochen__: if you make the referrer attribute reflect known values, you could inspect it by setting a policy and then seeing if the user agent kept it or returns the default value

[06:17:58.0000] <annevk>
jochen__: that's the normal way it works for HTML attributes

[06:18:22.0000] <jochen__>
ok

[06:18:29.0000] <jochen__>
at least the attribute would be a bit more useful then

[06:19:04.0000] <annevk>
jochen__: https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-known-values

[06:20:57.0000] <annevk>
jochen__: for fetch() we could also support both...

[06:21:31.0000] <annevk>
jochen__: fetch(url, {referrer:"/yay", referrerPolicy:"origin"})

[06:21:48.0000] <jochen__>
hum

[06:22:00.0000] <jochen__>
can we use something like referrerPath or something?

[06:22:13.0000] <jochen__>
if a.referrer is a policy, using referrer for the path in fetch is odd

[06:22:44.0000] <annevk>
I think that boat has sailed :/

[06:22:56.0000] <jochen__>
hurray for consistency

[06:23:00.0000] <annevk>
Request.prototype.referrer is a thing

[06:23:08.0000] <annevk>
We could still rename the attribute though, that hasn't shipped

[06:23:14.0000] <jochen__>
and I guess that's a full url, right?

[06:23:18.0000] <annevk>
yes

[06:23:28.0000] <jochen__>
yeah, then let's name the anchor thing referrerPolicy

[06:25:32.0000] <annevk>
okay, I'll try to write up all the bits in Fetch

[06:26:42.0000] <jochen__>
thx

[06:32:54.0000] <annevk>
philipj: I'll take another look at Fullscreen tomorrow

[06:36:07.0000] <annevk>
Hmm, Fetch is >4000 lines. Oh, DOM is >9000 lines.

[06:37:05.0000] <annevk>
Heh, HTML is >85000 lines

[06:37:49.0000] <philipj>
annevk: thanks, nothing urgent, just went through the open bugs to see if there was anything interesting

[06:40:43.0000] <wanderview>
annevk: do we have the proposal anywhere for storage boxes to do their own LRU?  not in the spec and the old wiki page just directs to here: https://storage.spec.whatwg.org/

[06:40:58.0000] <wanderview>
or just the concept of temporary

[06:41:11.0000] <annevk>
wanderview: https://wiki.whatwg.org/wiki/Storage#Cache_boxes

[06:41:31.0000] <annevk>
wanderview: the wiki page is marked obsolete, but still contains all the old info

[06:41:42.0000] <wanderview>
hmm... it didn't seem to show any of it to me

[06:42:26.0000] <annevk>
works in private mode too

[06:44:13.0000] <wanderview>
ok, I see the content there now

[06:44:17.0000] <wanderview>
I must just still be asleep

[07:02:47.0000] <wanderview>
annevk: can a redirect have an anchor ref on it?

[07:02:54.0000] <wanderview>
does that make sense?

[07:12:16.0000] <annevk>
wanderview: yes it can

[07:12:32.0000] <JakeA>
wanderview: step 19 suggest it can https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents

[07:12:46.0000] <JakeA>
Damnit, I'm always slower than annevk

[07:13:03.0000] <annevk>
well, your answer was more useful

[07:13:43.0000] <JakeA>
I'll take that as today's 'win'

[07:13:46.0000] <JakeA>
/me goes to bed

[07:14:32.0000] <annevk>
JakeA: fixed the redirect thing, though found some new issues to sort through with request's client and such...

[07:15:06.0000] <JakeA>
annevk: what are the issues?

[07:15:42.0000] <annevk>
JakeA: for client requests, request's client is null, but that is wrong as the request still needs to be added to some fetch registry

[07:16:02.0000] <wanderview>
annevk: can you confirm the only way Response.url can be set is via the fetch() function?

[07:16:05.0000] <annevk>
JakeA: and apparently Gecko tracks two "clients", a trigger and loading client

[07:16:38.0000] <annevk>
JakeA: haven't quite worked through how that is significant yet

[07:17:17.0000] <annevk>
wanderview: I'm not sure what that means

[07:17:33.0000] <annevk>
wanderview: I gotta go for a bit, back in an hour or so

[07:17:38.0000] <JakeA>
annevk: possibly for requests that may not create a client?

[07:17:52.0000] <JakeA>
wanderview: yeah, I believe that's the case. Manually created responses have an empty url

[07:18:08.0000] <wanderview>
JakeA: annevk: and Response.redirect() just sets the Location header... not the url

[07:18:17.0000] <JakeA>
Correct

[07:18:21.0000] <wanderview>
ok

[07:18:37.0000] <wanderview>
trying to help a contributor fix our Response.url getter to strip the anchor fragment

[07:18:52.0000] <wanderview>
thanks

[07:39:50.0000] <smaug____>
annevk: ok, atm looks like the github.io is a linux issue o_O

[07:40:02.0000] <smaug____>
I can access the address on non-linux systems

[07:40:19.0000] <smaug____>
this is fun

[07:51:52.0000] <annevk>
smaug____: URLs are lots of fun

[08:14:23.0000] <annevk>
wanderview: Response.redirect() is a shorthand for a synthetic response

[08:40:10.0000] <MikeSmith>
does Opera 12 have something built in that causes it to automatically send validation validation requests to the W3C validator?

[08:41:11.0000] <MikeSmith>
the #1 user agent I see by far in the validator logs is Opera/9.80 (Windows NT 6.2; Win64; x64) Presto/2.12.388 Version/12.16

[08:41:40.0000] <annevk>
Domenic: the main thing that's holding me back from adding promises to places is actually deciding between rejection and fulfilling

[08:42:13.0000] <Ms2ger>
MikeSmith, I remember it having something like that

[08:42:21.0000] <Ms2ger>
MikeSmith, or semi-automatically

[08:42:21.0000] <annevk>
Domenic: that is, Notification.requestPermission() and requestFullscreen()/exitFullscreen()

[08:42:26.0000] <annevk>
philipj: ^^

[08:42:35.0000] <MikeSmith>
Ms2ger: ok that would explain it then I guess

[08:44:23.0000] <MikeSmith>
it seems to account for 13.5% of all the requests the validator receives

[08:48:01.0000] <caitp>
that's strange given the market share can't be more than a sliver

[08:49:40.0000] <annevk>
Yeah, that seems unlikely... There's right-click to validate option iirc, but accounting for 13.5%... Perhaps a bot?

[08:50:16.0000] <Ms2ger>
Especially with nobody using Opera anymore

[08:54:20.0000] <MikeSmith>
well there's a weird pattern to the referres

[08:54:34.0000] <MikeSmith>
*referrers

[08:54:44.0000] <MikeSmith>
they're all things like this:

[08:54:46.0000] <MikeSmith>
http://webtsf.bidbuy.co.kr/translation/?bbOpt=100011&bbUrl=http://validator.w3.org/check?uri=http%3A%2F%2Fvgn.vn%2Fflash%2Fprofile%2Falizaschurr

[08:55:57.0000] <MikeSmith>
e.g., some URL with the validator URL as a query param

[08:56:09.0000] <MikeSmith>
but randome other than that

[08:57:25.0000] <annevk>
perhaps it's some Russian bot network using Opera?

[08:57:25.0000] <MikeSmith>
I mean there's otherwise no pattern to the URL of the referring site not to the value of the "uri" param in the part that's a URL for the validator

[08:57:31.0000] <MikeSmith>
yeah seems like

[08:57:40.0000] <annevk>
maybe that's why Opera is popular in Russia

[08:57:42.0000] <MikeSmith>
gotta be something like that

[08:57:45.0000] <annevk>
:-P

[08:57:53.0000] <MikeSmith>
heh

[08:58:07.0000] <Domenic>
annevk: right, yeah. For methods named request I can go either way. I guess we have some minor precedent for rejecting with some of the newer permission-requesters.

[08:58:40.0000] <annevk>
Hmm, I really dislike throwing methods

[08:58:56.0000] <annevk>
Well, unless it's truly exceptional, but permissions don't feel like that

[09:02:22.0000] <TabAtkins>
I used to hate throwing methods, but working with more Python made me tolerate them more.

[09:02:39.0000] <philipj>
annevk, Domenic, with Notification.requestPermission(), are we talking about requesting fullscreen permission up-front?

[09:03:24.0000] <philipj>
MikeSmith: I think some version of Opera desktop had a "validate" thing in the context menu actually

[09:03:32.0000] <Domenic>
philipj: you mean for requestFullscreen?

[09:03:54.0000] <philipj>
MikeSmith: confirmed, Opera 12.16 has this (terrible idea, right?)

[09:04:18.0000] <philipj>
Domenic: well, I'm trying to understand what annevk wanted me to comment on above :)

[09:05:12.0000] <annevk>
philipj: Notificaiton.requestPermission() is another API we want to return a promise for

[09:05:23.0000] <annevk>
philipj: and it's not clear what the reject/fulfill tradeoff is

[09:06:32.0000] <Domenic>
Let's be sure I'm remembering the precedent right.

[09:06:44.0000] <philipj>
annevk: oh, I thought you were talking about difficulties with having requestFullscreen() return a promise

[09:06:59.0000] <Domenic>
Well, permissions API .request() is totally unspecified, so that's no help...

[09:07:23.0000] <philipj>
What is the tradeoff anyway? Whether or not to let scripts know that they don't have permission? o_O

[09:07:56.0000] <Domenic>
no, whether to say true/false for permission, or to fulfill/reject

[09:08:01.0000] <Domenic>
s/say/fulfill with/

[09:08:11.0000] <Domenic>
basically, is it exceptional to be denied permission when requesting it

[09:08:12.0000] <philipj>
oh, I see

[09:08:30.0000] <philipj>
Promise<boolean> that always fulfils vs. Promise<void> that can be rejected?

[09:08:55.0000] <Domenic>
yep

[09:09:31.0000] <philipj>
I see. Considering code like requestPermission("foo").then(function() { doIt(); }) it seems less error-prone to reject

[09:09:58.0000] <Domenic>
yeah but consider code like `await requestPermission("foo")`

[09:10:13.0000] <Domenic>
Should it be `if (await requestPermission("foo")) { doIt(); } else { dontDoIt(); }`

[09:10:38.0000] <Domenic>
or should it be `var ok = false; try { requestPermission("foo"); ok = true; } catch (e) { dontDoIt(); } if (ok) { doIt(); }`

[09:11:04.0000] <Domenic>
the latter being worst-case I guess; if it's truly exceptional you would let it bubble and handle it at a higher level.

[09:11:08.0000] <philipj>
I hadn't even seen the syntax for await until now, so I'm afraid I'm of no use here

[09:11:27.0000] <Domenic>
the latter line should be `try { await requestPermission("foo"); ...`

[09:12:20.0000] <philipj>
so when using await, a rejected promise will throw an exception, right?

[09:12:26.0000] <philipj>
/me reads http://jakearchibald.com/2014/es7-async-functions/

[09:14:19.0000] <Domenic>
Yep

[09:14:24.0000] <Domenic>
I am coming around to bool

[09:14:29.0000] <Domenic>
(Or PermissionStatus)

[09:15:39.0000] <philipj>
Don't know about Notification.requestPermission(), but in the case of requestFullscreen() I think it would be pretty odd to not reject in the case where we currently fire fullscreenerror

[09:18:13.0000] <Domenic>
Agreed, those are true error cases though right? Not just denial.

[09:19:09.0000] <philipj>
Right, at this point they're cases where the API has been used incorrectly

[09:19:22.0000] <Domenic>
+1

[09:19:33.0000] <Domenic>
OK, I entered all this reasoning into https://github.com/w3c/permissions/issues/41

[09:19:36.0000] <philipj>
There was a time when people wanted to ask for permission before entering fullscreen, in a kind of two-step model, but that time has passed

[09:19:41.0000] <Domenic>
Hopefully nobody will disagree strongly.

[09:19:51.0000] <philipj>
Just use many words and everyone will agree.

[09:47:07.0000] <annevk>
philipj: so fulfill with undefined, reject with TypeError?

[09:48:19.0000] <philipj>
annevk: maybe fulfil with the element that is now fullscreen, or would that be un-idiomatic?

[09:48:28.0000] <philipj>
I guess you could look at document.fullscreenElement

[09:48:59.0000] <annevk>
yeah, it's also the element you just invoked the method on

[09:49:54.0000] <philipj>
so fulfil with undefined seems OK, if there's strong guarantee that document.fullscreenElement inside the promise callback will be the element that you requested fullscreen on

[09:50:13.0000] <philipj>
I'm not sure it will be in weird cases where you request fullscreen on two elements at once, though?

[09:50:41.0000] <annevk>
I guess, or if you invoke requestFullscreen from the event?

[09:53:59.0000] <philipj>
but then, you can still know which event you requested fullscreen on, so also passing it to the callback might confuse people about why this is so

[09:54:02.0000] <philipj>
so let's not

[09:54:13.0000] <philipj>
as for rejection, as TypeError the typical thing?

[09:54:25.0000] <philipj>
s/as/is/?

[09:55:14.0000] <Ms2ger>
I believe so

[09:56:57.0000] <philipj>
If so that WFM, annevk

[09:57:24.0000] <annevk>
I TypeError all the things :-)

[09:57:36.0000] <annevk>
It's the new DOMException

[09:57:47.0000] <Domenic>
Hmm https://w3c.github.io/push-api/#widl-PushManager-subscribe-Promise-PushSubscription--PushSubscriptionOptions-options rejects with PermissionDeniedError for not-granted.

[09:58:20.0000] <Domenic>
annevk: isn't it fulfill with true? Or fulfill with false if permission is denied?

[09:58:36.0000] <annevk>
Domenic: not if we're going to reject for fullscreenerror events

[09:58:53.0000] <Domenic>
Right I guess fullscreen is a weird one here.

[09:58:58.0000] <philipj>
If permission is denied you exit fullscreen again

[09:59:04.0000] <Domenic>
yeah

[09:59:25.0000] <Domenic>
it's barely asynchronous, really... just a turn or two of the event loop for rendering stuff to happen.

[09:59:27.0000] <philipj>
annevk: I've noticed you like TypeError a lot, is there some consensus that it's the new black, or are other editors going on other types?

[09:59:42.0000] <annevk>
always fulfill with PermissionStatus makes sense for Notification I think

[10:00:01.0000] <philipj>
Domenic: well, that and actually doing the resize on the browser side

[10:00:14.0000] <annevk>
philipj: not sure, I'm mostly trying to be more compatible with non-browser JavaScript

[10:00:53.0000] <annevk>
philipj: and Allen has this philosophy that branching on exceptions isn't really done in JavaScript, which seems mostly true

[10:01:09.0000] <philipj>
annevk: right, so the choices are EvalError, RangeError, ReferenceError, TypeError and URIError?

[10:01:31.0000] <annevk>
philipj: mostly Range and Type

[10:01:54.0000] <philipj>
RangeError for things like index out of bounds?

[10:02:00.0000] <annevk>
philipj: yeah

[10:02:04.0000] <philipj>
btw, is it possible use just Error?

[10:02:17.0000] <philipj>
for things that just don't have anything to do with types?

[10:02:20.0000] <annevk>
philipj: I guess, not sure if JavaScript does that anywhere

[10:02:41.0000] <philipj>
oh well, I won't interfere with that, just curious :)

[10:04:27.0000] <annevk>
philipj: the other thought is uplifting features to be JavaScript builtin libraries

[10:04:54.0000] <annevk>
philipj: doesn't apply much to Fullscreen and Notifications I guess, but would e.g. for URL

[10:06:17.0000] <philipj>
Well... it'd be hard to ensure consistent internal and web-facing behavior for URLs then, but sure, there are definitely some bits that may eventually be in JS.

[10:37:33.0000] <annevk>
Microsoft's Web Component strategy is surprisingly similar to that of Mozilla

[10:39:48.0000] <annevk>
philipj: perhaps we should fulfill with true if something changed and false if nothing changed?

[10:40:02.0000] <annevk>
philipj: was just reading your comment in Bugzilla

[10:59:38.0000] <smaug____>
annevk: they sent some new information ?

[10:59:45.0000] <smaug____>
MS

[11:01:00.0000] <annevk>
waiting for bit.ly and to.co...

[11:01:04.0000] <annevk>
smaug____: they wrote http://blogs.windows.com/msedgedev/2015/07/15/microsoft-edge-and-web-components/

[11:01:22.0000] <annevk>
smaug____: doesn't say much

[11:05:50.0000] <wanderview>
annevk: they at least gave a rough ordering of features they woudl implement

[11:06:15.0000] <wanderview>
template, shadow dom, custom element

[11:06:45.0000] <annevk>
yeah, that's also roughly the order of stable to unclear

[11:07:20.0000] <annevk>
I wonder if anyone has any tricks up their sleeve for custom elements

[11:08:06.0000] <annevk>
Other than making a decision that we hope JavaScript won't restrict private state to constructors and run with it...

[11:14:21.0000] <Domenic>
I have a trick I've been working on...

[11:14:51.0000] <Domenic>
It's still about three-quarters baked, so I haven't sent it anywhere, but you can poke around my GitHub...

[11:15:00.0000] <annevk>
Heh

[11:15:19.0000] <Domenic>
"we in FirefoxOS no longer are working on creating a "web apps" platform" ???? from https://groups.google.com/forum/#!topic/mozilla.dev.platform/RAHBNdesiXs

[11:15:26.0000] <annevk>
I'll have a look, was afraid that meeting was going to be sad

[11:15:35.0000] <tantek>
wat

[11:16:09.0000] <annevk>
Domenic: Mozilla co-opted "web apps" at some point to mean iOS/Android-style apps with web technology, iirc

[11:16:29.0000] <Domenic>
oh... that makes more sense...

[11:16:30.0000] <annevk>
Domenic: i.e., packages

[11:18:10.0000] <annevk>
Though I think also Firefox OS shifted thinking somewhat from being about applications to just being about the web, but I haven't really seen any demos

[11:18:24.0000] <tantek>
annvevk I'm starting to think that the whole "JSON side-file" approach is a giant anti-pattern as all it does it provide another vulnerable surface for JSONLDists to attack.

[11:18:42.0000] <Domenic>
hahahahahaha

[11:19:42.0000] <annevk>
tantek: that thread really could use some JSON-LD trolling...

[11:19:43.0000] <tantek>
Doesn't "app" just mean "something that requires more work for the user to find, install, update, because apparently users prefer to futz with re-arranging icons on a homescreen more than actually do anything useful" ?

[11:20:29.0000] <annevk>
Yeah, it's not clear that "apps" are actually a great thing for the web to try to emulate

[11:21:13.0000] <annevk>
This whole game of playing to the strengths of native is getting old

[11:21:51.0000] <tantek>
yup

[11:22:23.0000] <wanderview>
annevk: my understanding is the current plan is for fxos "apps" to just be SW-enabled pages... dangerous APIs will require the content to be in a signed package, though

[11:22:28.0000] <tantek>
for some reasons "native" popularized "install" as more sexy than "bookmark" even though they're basically the same thing (modulo pre-caching etc.)

[11:23:07.0000] <annevk>
tantek: yes, that has been my party-line for years, and yet folks still insist on "install" being a separate thing, as e.g. happens in that thread

[11:23:10.0000] <tantek>
also 2D views of "installed" icons, vs. 1D lists of "bookmarked" text titles and URLs

[11:23:22.0000] <tantek>
annevk, cheers.

[11:24:52.0000] <annevk>
tantek: https://the-pastry-box-project.net/anne-van-kesteren/2013-december-2

[11:25:10.0000] <tantek>
annvek, but wait, it's not enough to be able to "bookmark" AND "install", we need to be able to "pin" all the things too!

[11:25:21.0000] <annevk>
I'm not sure it's good or bad that I haven't adjusted my vision much since Dec 2013

[11:25:50.0000] <tantek>
annevk: that's what you get for being "visionary"

[11:26:21.0000] <Domenic>
i don't think the term matters. install is most familiar to users. bookmark connotes things that only work online.

[11:26:30.0000] <tantek>
HAHAHAHAHA

[11:26:47.0000] <Domenic>
and yes, i know that back in the day firefox's offline mode used to be awesome

[11:26:53.0000] <tantek>
most (90%+?) of the "native" apps I've seen installed only work online

[11:27:05.0000] <Domenic>
but these days everybody says no-cache on their homepage

[11:27:09.0000] <annevk>
iOS uses "[GET]", not install

[11:27:42.0000] <tantek>
annevk - true, I think that changed in iOS7 (from [Install] to [Get] in the Apple App Store)

[11:27:48.0000] <Domenic>
native apps "work" offline, in that they display branded error pages saying "this app needs internet for reason X" instead of "DNS_NETWORK_ERR_NOT_CONNECTED"

[11:28:03.0000] <tantek>
hahaha awesome

[11:28:12.0000] <Domenic>
that's a big difference

[11:28:15.0000] <annevk>
I think that's actually a valid point

[11:28:26.0000] <annevk>
And I think I might use a service worker for site just for that

[11:28:27.0000] <tantek>
Domenic: we need a gallery of all those branded error pages with a caption - "How's your native offline support doing now?"

[11:28:33.0000] <annevk>
Offline branding

[11:28:40.0000] <Domenic>
annevk: yep, +1

[11:28:43.0000] <tantek>
sounds like a posterframe

[11:29:05.0000] <Domenic>
annevk: was vaguely thinking manifest/splash screen stuff could maybe help with auto-generation of such pages, but SW will of course give the most power.

[11:29:47.0000] <Domenic>
annevk: also https://github.com/whatwg/resources.whatwg.org/issues/7 and https://github.com/whatwg/resources.whatwg.org/issues/6 :)

[11:44:16.0000] <TabAtkins>
annevk: Any chance you could define "sibling list" of an object in DOM?  Would be the object and all of its siblings.

[11:44:41.0000] <TabAtkins>
bz is asking me to clarify what Selectors means when :nth-child() talks about siblings, for elements without a parent.

[12:34:43.0000] <annevk>
TabAtkins: you can't have siblings without a parent

[12:36:13.0000] <Tshot>
Hi guys, anyone in here?

[12:43:36.0000] <TabAtkins>
annevk: Exactly. But you are the sole element in your sibling list in that case.

[12:43:41.0000] <TabAtkins>
You don't have any *other* siblings.

[12:45:30.0000] <annevk>
TabAtkins: it sounds like you want something like siblings or self

[12:45:55.0000] <Domenic>
specifiction really feels like the new public-html

[12:46:00.0000] <m2n>
Hello, Can somebody suggest me how can I include multiple values in a header in the single request. like setRequestHeader("%d = %d",a,b) ? So, basically I want to set the custom header here ?

[12:46:17.0000] <TabAtkins>
Domenic: That's the definition of "open to the public, and browser vendors don't pay much attention", yes.

[12:46:41.0000] <Domenic>
a shame, it's so much more readable on mobile

[12:47:00.0000] <TabAtkins>
annevk: Yes, that's what I want.  Well, siblings *and* self.  The data structure that :nth-child() et al operate on.

[12:47:03.0000] <Domenic>
maybe someone could pay ForbesLindesay to revamp readable-email.org. It was a good start but needs more love.

[12:47:15.0000] <TabAtkins>
Without a parent, you're the only element in your sibling list, so you match :first-child and :last-child.

[12:48:23.0000] <annevk>
TabAtkins: note that nothing in https://dom.spec.whatwg.org/#trees uses "list"

[12:48:42.0000] <Domenic>
TabAtkins: nothing in https://github.com/tabatkins/bikeshed/blob/master/docs/infotree.md for comments?

[12:48:49.0000] <TabAtkins>
annevk: Sure, is that relevant?

[12:49:02.0000] <TabAtkins>
Domenic: Not yet, but I'm happy to add if you want them.  What format?

[12:49:24.0000] <Domenic>
TabAtkins: I was thinking # for until-end-of-line

[12:49:27.0000] <annevk>
TabAtkins: I'd prefer some term that matches the existing set

[12:49:37.0000] <TabAtkins>
Domenic: Yeah, that's my first impulse as well.

[12:49:49.0000] <annevk>
TabAtkins: ah, inclusive sibling is prolly it

[12:49:50.0000] <TabAtkins>
Gimme a bit to finish what I'm working on and I'll implement.

[12:49:56.0000] <annevk>
TabAtkins: file an issue?

[12:50:02.0000] <Domenic>
TabAtkins: although I found "personal" as a group so I no longer need `Group: WHATWG # I like their CSS better`

[12:50:23.0000] <TabAtkins>
Domenic: ???

[12:50:37.0000] <Domenic>
TabAtkins: I am doing a personal spec and got momentarily stuck on what group to put

[12:50:58.0000] <TabAtkins>
Oh. I... was going to remove personal, as it's really "Tab's personal specs".

[12:50:59.0000] <Domenic>
My first instinct was WHATWG with a comment saying "this is actually just a personal spec"

[12:51:04.0000] <Domenic>
oh lol

[12:51:10.0000] <TabAtkins>
But wtv

[12:51:36.0000] <TabAtkins>
Like, it includes some things that are specific to the dir structure of my github. ^_^

[12:51:47.0000] <Domenic>
haha ok well we'll see how this goes

[12:51:57.0000] <TabAtkins>
I guess that's just Prism, from before I added syntax highlighting to Bikeshed at all.

[12:52:14.0000] <TabAtkins>
Domenic: You can just omit the Group, you know.

[12:52:29.0000] <Domenic>
TabAtkins: that gives csswg I'm told

[12:52:43.0000] <TabAtkins>
Domenic: No? I mean, it uses the same stylesheet.

[12:53:04.0000] <Domenic>
Group must contain the name of the group the spec is being generated for. This is used by the boilerplate generation to select the correct file. It defaults to "csswg".

[12:53:11.0000] <Domenic>
from https://github.com/tabatkins/bikeshed/blob/master/docs/metadata.md

[12:53:16.0000] <TabAtkins>
Oh, I need to update that documention, sorry.

[12:53:25.0000] <Domenic>
oh cool

[12:54:03.0000] <TabAtkins>
Omitted group is explicitly no group. It uses the standard CSSWG styling, but it has a CC0 copyright license by default and doesn't do anything weird about SotD or anything.

[12:56:00.0000] <Domenic>
sounds perfect


2015-07-16
[23:08:58.0000] <annevk>
For a moment I thought inclusive siblings would let me get rid of contiguous Text nodes, but alas...

[00:16:44.0000] <annevk>
In the category everything old is new again: https://github.com/whatwg/fetch/issues/83

[01:21:25.0000] <annevk>
mkwst: https://fetch.spec.whatwg.org/#client-request is the set of terms of we have today

[01:21:44.0000] <annevk>
mkwst: we could rename resource request to subresource request, but that still wouldn't include workers

[01:22:07.0000] <annevk>
mkwst: we could make it include workers, and then name the other type "non-worker subresource request"?

[02:19:01.0000] <hgl>
annevk, why fetch couldn't return document directly like xhr does? is there something prevents res.document() to work?

[02:20:25.0000] <annevk>
hgl: we mostly decided we didn't want the Fetch layer to depend upon the HTML parser

[02:20:33.0000] <annevk>
(and all of DOM)

[02:21:01.0000] <annevk>
once streams are out I'm sure something will come along that plugs all these pieces together

[02:21:19.0000] <hgl>
annevk, just saw issue #16 too on github too. thanks for the explanation. makes sense.

[02:34:10.0000] <smaug____>
annevk: what is your opinion on custom ctors ?

[02:35:16.0000] <annevk>
smaug____: I would love it if we could make them work as I think that's ultimately what developers want, a mapping between markup and JS objects

[02:35:53.0000] <annevk>
smaug____: and anything that doesn't expose the constructor will have a hard time competing with libraries that do manage to expose the constructor down the line

[02:36:14.0000] <smaug____>
right

[02:36:23.0000] <annevk>
(even harder if the JavaScript language evolves and adds features that depend on the constructor)

[02:36:39.0000] <smaug____>
and can you imagine what the spec would look like for this, for all sorts of edge cases?

[02:36:56.0000] <smaug____>
my worry is really in the spec level

[02:37:18.0000] <smaug____>
perhaps I worry too much

[02:37:35.0000] <annevk>
For the HTML parser it seems doable, since there's already a script-synchronization point. Although obviously it requires work and careful checks...

[02:38:57.0000] <annevk>
For cloneNode() and such I have not tried to figure out the implications yet. I know mutation events were hard, but I am convinced we could define how they work today if we needed to. That kind of complexity becomes more trivial with the algorithms we have written down today.

[02:39:14.0000] <annevk>
However, getting all the browser code in line...

[02:40:28.0000] <annevk>
Domenic has some kind of intermediate proposal that does not expose constructors for now (the browser still allocates the objects), but would allow them to be added in the future. Basically an element registry that only exposes a "get", not a "set"...

[02:40:59.0000] <annevk>
(And on top of that you'd keep lifecycle callbacks, perhaps generalized to all elements rather than just custom elements.)

[02:41:44.0000] <annevk>
I think that might be a nice way to ship custom elements without solving the hard problem, while keeping the door open for solving it later...

[02:44:32.0000] <smaug____>
so DOM spec, including Range, and anything using Range might need some tweaks.

[02:45:03.0000] <smaug____>
since suddenly after using certain range methods, the world around you might look totally different

[02:46:58.0000] <annevk>
Yeah, if we do custom constructors in v1 and not Domenic's way out we'd have to do that

[02:47:42.0000] <annevk>
Define cloning in a way that makes it clear it operates on a live tree and then define everything that needs to do cloning in terms of that somehow...

[04:48:54.0000] <annevk>
wanderview: hey, are you awake?

[04:49:11.0000] <annevk>
wanderview: I was wondering, for https://github.com/whatwg/fetch/issues/55 we wanted to introduce the "obsolete flag"

[04:49:33.0000] <annevk>
wanderview: however, couldn't we simply check if the used flag is set even if the body is null?

[04:49:41.0000] <annevk>
JakeA: ^^

[04:59:04.0000] <JakeA>
annevk: so this problem is created by the transfer of body? If so, I agree with you, move the bodyUsed check before the if-body-not-null

[04:59:55.0000] <annevk>
yeah, it seems we only ever set the used flag if input's body was non-null to begin with

[05:00:41.0000] <annevk>
alright, I'll fix that

[05:00:51.0000] <annevk>
then next Wednesday we can worry about the rest :-)

[05:02:24.0000] <JakeA>
annevk: unfortunately i'm not going to make the Wednesday as I have a flight to Austin for TXJS, but the other people in the room know more than me about streams anyway

[05:02:50.0000] <annevk>
JakeA: I see, will you be there Monday?

[05:03:04.0000] <JakeA>
annevk: yep, and Tuesday

[05:03:11.0000] <annevk>
JakeA: I was kind of hoping we could cover cancelable stuff too

[05:03:16.0000] <annevk>
JakeA: for custom elements?

[05:03:44.0000] <annevk>
JakeA: especially if sleevi is there the security concerns around cancelation and streams in general

[05:03:48.0000] <JakeA>
annevk: I don't know much about custom elements, so dunno if it's worth me going to that meeting, but I'll be in the vicinity

[05:04:15.0000] <annevk>
JakeA: guess we'll mostly hang out Monday then; I'm in town Sunday too

[05:06:22.0000] <JakeA>
annevk: I arrive 14:35 on Sunday, so definately time for food & drinks Sunday evening if you're around

[05:06:33.0000] <annevk>
sounds good

[05:22:05.0000] <annevk>
So I was going to allow not teeing a request if you disable redirects and disable dialogs and such (through setting request's window to "no-window") but it mentions something about the Headers maybe changing...

[05:22:23.0000] <annevk>
I'm kind of glad I leave notes for myself, but they could be a little clearer

[05:23:40.0000] <annevk>
Ah okay, I think I figured it out...

[06:40:28.0000] <wanderview>
annevk: it was a rare morning and i indeed was asleep

[06:42:56.0000] <annevk>
nice

[07:48:29.0000] <wanderview>
annevk: is anyone working on wpt tests for the fetch spec yet?

[07:48:39.0000] <annevk>
wanderview: not that I know of

[07:48:52.0000] <annevk>
wanderview: I created some tests for nosniff...

[08:26:08.0000] <annevk>
Any volunteers for converting Fetch to bikeshed?

[08:27:39.0000] <philipj>
annevk: Not me, but whoever does it make sure to insert plenty of typos in the manual id=some-section that Bikeshed will ask you to write. TabAtkins ;)

[08:29:10.0000] <TabAtkins>
Fetch is only half as long as DOM, easy-peasy.

[08:29:26.0000] <TabAtkins>
Judging by my past performance, should only take a month. ^_^

[08:43:07.0000] <Domenic>
Do Web IDL :P

[08:44:46.0000] <annevk>
IDL in bikeshed would be great

[08:44:54.0000] <annevk>
idl.spec.whatwg.org would be even better...

[08:46:17.0000] <philipj>
annevk: I see https://compat.spec.whatwg.org/ is now live, do you know who'll be editing it, for the most part?

[08:47:04.0000] <annevk>
miketaylr I think

[08:47:09.0000] <philipj>
cool

[08:47:27.0000] <philipj>
Is this the first step towards Gecko following Edge in pretending to be Chrome?

[08:47:32.0000] <miketaylr>
yeah, just trying to finish up some other junk this week before having more time

[08:47:45.0000] <miketaylr>
philipj: but contributions welcome ^_^

[08:48:13.0000] <philipj>
miketaylr: I'll just file the bugs and tell you the commas are in the wrong places ;)

[08:48:15.0000] <miketaylr>
philipj: not so much pretending to be chrome, just trying to make the mobile web work

[08:48:18.0000] <miketaylr>
heh fair

[08:48:29.0000] <miketaylr>
the Asian web especially

[08:48:55.0000] <miketaylr>
Gecko does pretty well in the West, but in Japan and China things are... rough.

[08:49:23.0000] <philipj>
miketaylr: yeah, but so far both browsers who began adding some webkit things ended up either being Chromium (Opera) or pretending to be as well as possible (Edge)

[08:49:42.0000] <miketaylr>
yeah.

[08:49:48.0000] <miketaylr>
i remember when we tried the same thing at opera

[08:49:56.0000] <miketaylr>
starting with webkit prefixes...

[08:50:15.0000] <miketaylr>
iirc, for the same reasons: japan compat

[08:50:17.0000] <philipj>
I happen to think that would be great, chuck away all the prefixes except those webkit ones that are required, and forget about the IE and Gecko code paths in existing content

[08:50:42.0000] <philipj>
A lot of work though, and likely a rough transition :/

[08:50:58.0000] <miketaylr>
to the extent possible i'd like to define supporting these things in terms of mappings to existing standard stuff

[08:51:00.0000] <philipj>
Plus nothing but hate from developers who will promise to block you forever

[08:51:03.0000] <miketaylr>
sort of like polyfills i guess

[08:51:31.0000] <miketaylr>
heh, i'm familiar with developer hate

[08:51:54.0000] <philipj>
miketaylr: some things can probably simply be defined in terms of JavaScript entirely, definitely webkitMatchesSelector could

[08:52:02.0000] <miketaylr>
yeah

[08:52:03.0000] <philipj>
but then an alias is trivial in prose too

[08:52:22.0000] <philipj>
In any event, best of luck, you won't get any hate from me, unless you put the commas in the wrong places :)

[08:52:28.0000] <miketaylr>
hehe, thanks

[09:27:16.0000] <Domenic>
So basically T[] is used in HTML and CSSOM

[09:27:23.0000] <Domenic>
Better than I expected

[10:05:55.0000] <annevk>
Hmm, I wonder where we documented why mutation events are problematic

[10:22:09.0000] <annevk>
https://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html is it btw

[10:30:58.0000] <Domenic>
execCommand() woof

[10:31:18.0000] <Domenic>
I guess that's subsumed under editing though which i already knew about

[10:31:42.0000] <annevk>
wanderview: so technically 2.2 'request's mode is not "no-cors" and response's type is "opaque".' is a bit of a hack

[10:32:45.0000] <annevk>
wanderview: if APIs truly worked on the response (and knew not to poke at the internal response), they would basically fail for those too

[10:33:14.0000] <annevk>
wanderview: actually, I guess it's a nice convenience since it gives the API less response types to distinguish, meh

[10:33:58.0000] <annevk>
Is that still at https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html these days?

[10:34:03.0000] <annevk>
No love for that...

[10:35:56.0000] <Domenic>
It's got to be somewhere else...

[10:36:31.0000] <annevk>
https://w3c.github.io/editing/ has pointers

[10:37:12.0000] <Domenic>
Ah this is the evolution thereof https://w3c.github.io/editing/execCommand.html

[10:37:25.0000] <annevk>
looks pretty bad this arbitrary splitting on features

[10:37:55.0000] <Domenic>
Meh

[10:38:11.0000] <annevk>
I keep trying to tell people to focus on the model, but...

[10:41:24.0000] <annevk>
E.g. the beforeinput/input thing is completely unclear about how these events get triggered and how that relates to the event loop and other things going on

[10:54:36.0000] <annevk>
"Made with love by the libuv team. — libuv is for C projects that miss the joy of javascript callback hell."

[11:00:05.0000] <Domenic>
haha never seen that before

[11:02:07.0000] <TabAtkins>
Ugh, doing WebIDL is on my list, yeah.

[11:02:21.0000] <TabAtkins>
Kinda considering taking a week or two off of work and just spending a few hours a day doing Bikeshed things.

[11:02:25.0000] <TabAtkins>
And the rest video games.

[11:08:37.0000] <TabAtkins>
Also: considering auto-adding the commit id to a <meta> when you generate, if you do so from a git repo.  Makes it easier to look up historical revisions without having to do sleuthing to try and match up the commit.  Good/bad idea?

[11:10:10.0000] <Domenic>
+1

[11:10:18.0000] <Domenic>
Already doing similar things for streams

[11:10:31.0000] <TabAtkins>
via a custom macro or something?

[11:10:52.0000] <Domenic>
Yeah, https://github.com/whatwg/streams/blob/master/deploy.sh#L52-L53

[11:30:15.0000] <annevk>
There's still some references issues with bikeshed

[11:30:38.0000] <annevk>
But overall I like it better than Anolis

[11:31:10.0000] <Ms2ger>
It helps that it's maintained :)

[11:36:01.0000] <TabAtkins>
annevk: Yeah, I'm still not 100% happy with my handling of IDL, but I'm gradually iterating it towards goodness.

[11:36:51.0000] <annevk>
TabAtkins: also WHATWG vs W3C normative references is a bit of a pain

[11:36:58.0000] <TabAtkins>
Ugh, I know.

[11:36:59.0000] <annevk>
TabAtkins: but maybe that's mostly specref

[11:37:11.0000] <TabAtkins>
Yeah, it's specref. Tobie's trying to be even-handed.

[11:37:17.0000] <TabAtkins>
Which is frustrating when it's wrong. ^_^

[11:37:43.0000] <TabAtkins>
But then I have mikewest on the other side preferring W3C refs for something or other, which I've so far mostly ignored.

[11:38:03.0000] <annevk>
mkwst: really? :/

[11:38:12.0000] <annevk>
I am disappoint

[11:38:35.0000] <philipj>
heretic!

[11:39:41.0000] <jsbell>
TabAtkins: to get a "webapps" bikeshed group/template... send you a PR or ...?

[11:40:03.0000] <TabAtkins>
jsbell: Yup. Probably just fork off of the csswg ones or something.

[11:40:59.0000] <jsbell>
kk. Don't hold your breath tho.

[11:41:26.0000] <TabAtkins>
No skin off my nose.

[11:43:21.0000] <TabAtkins>
heycam|away: "behahvior"

[14:36:09.0000] <Domenic>
hober: othermaciej: any chance we can get you guys to comment on https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0159.html ?

[14:47:28.0000] <hober>
Domenic: ok

[14:51:06.0000] <hober>
Domenic: I don't think our position has changed much since https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0225.html (see II.B. & II.C. in that email)

[14:52:52.0000] <Domenic>
hober: OK, got it. Note that upgrading and synchronous constructors are somewhat orthogonal. But if you guys think sync constructors are OK, could you maybe help me with https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0180.html ?

[14:55:00.0000] <hober>
Domenic: i'll take a look

[15:05:22.0000] <othermaciej>
Domenic: we'll look at it more closely and we'll send an update about our issue stances in general (maybe not til Monday in the worst case but def before the meeting)

[15:05:34.0000] <Domenic>
othermaciej: awesome, thank you.

[16:22:55.0000] <danbeam>
what would one expect from docFrag.querySelector(':root')?

[16:25:28.0000] <danbeam>
css selectors 4 says "an element that is the root of the document"

[16:25:44.0000] <danbeam>
does a DocumentFragment count? :)

[16:44:31.0000] <TabAtkins>
danbeam: DocumentFragment isn't an element.

[16:44:48.0000] <TabAtkins>
So the answer is null, or whatever querySelector returns when it doesn't find anything.


2015-07-17
[17:16:32.0000] <Domenic>
TabAtkins: what is <css>

[17:20:58.0000] <TabAtkins>
Domenic: A shorthand for <span class="css">, for when we want to mark up something to look like a keyword but not actually link to anything (because there's no such definition, or too many, or what have you).

[17:47:41.0000] <wanderview>
annevk: JakeA: if a controlled document is in the bfcache, do we need to fire fetch events for it when the user hits the back button to return to the page? or basically not because network is not normally done there

[17:48:02.0000] <wanderview>
just a random thought I had this evening (I need a hobby)

[17:58:23.0000] <danbeam>
TabAtkins: well, I'd expect it to find the first element in the DocumentFragment

[17:58:27.0000] <danbeam>
TabAtkins: not the fragment itself

[18:00:31.0000] <TabAtkins>
danbeam: Those aren't document roots. But I defined a :top-level pseudo to do what you're thinking

[18:03:35.0000] <danbeam>
TabAtkins: the only reason I need :root or :top-level or whatever is that I'm trying to do piercing from a root to find everything with a certain attribute name (across shadow DOMs)

[18:03:53.0000] <danbeam>
currently that entails .querySelector(':root /deep/ [attr]')

[18:04:07.0000] <danbeam>
i'd prefer just... /deep/ [attr]

[18:04:10.0000] <danbeam>
but that throws

[18:04:41.0000] <danbeam>
is there a better way to accomplish a query through all shadow roots?

[18:04:51.0000] <danbeam>
that includes top-level elements?

[18:11:58.0000] <danbeam>
fwiw: [attr], ::shadow [attr] might work

[22:28:00.0000] <MikeSmith>
annevk: the test deployment of the TLS-enabled www.w3.org site is already helping to catch some bugs in the gecko CSP upgrade-insecure-requests implementation https://bugzilla.mozilla.org/show_bug.cgi?id=1183563#c7

[22:38:38.0000] <annevk>
MikeSmith++

[22:39:08.0000] <annevk>
MikeSmith: oh my god, our redirect code is sooo bad

[22:40:08.0000] <annevk>
wanderview: bfcache is not specified to that level of detail (and e.g. Chrome doesn't implement it)

[22:40:55.0000] <annevk>
danbeam: /deep/ is dead

[22:43:06.0000] <kochi>
annevk: /deep/ and ::shadow are still allowed for querySelector.

[22:43:20.0000] <annevk>
ah true

[22:43:41.0000] <annevk>
well, I'm not sure if everyone agreed to that, but yeah

[22:43:43.0000] <kochi>
I easily forget which one is static profile and which is dynamic profile

[22:46:06.0000] <kochi>
Hmm, http://dev.w3.org/csswg/selectors/ , selectors you can write in CSS stylesheets are 'dynamic' profile, while what you can write for querySelector() is 'static' profile.

[22:46:23.0000] <kochi>
So /deep/ and ::shadow are likely to remain in 'static' profile.

[22:46:46.0000] <annevk>
They should've just called "dynamic" "live", which is what the rest of the world calls it

[22:46:53.0000] <annevk>
Perhaps it didn't go to Last Call yet...

[22:48:32.0000] <kochi>
Maybe I'm the only one, but I feel calling selectors in CSS stylesheet file 'dynamic' quite weird, because such CSS stylesheet file is quite static :)

[22:49:04.0000] <kochi>
They are just matched against dynamic things (DOM).

[22:51:20.0000] <MikeSmith>
annevk: yeah I guess that gecko bug exposes an underlying problem that's not specific just to upgrade-insecure-requests

[22:51:57.0000] <annevk>
kochi: well, they're continuously matched, whereas querySelector() is matched once

[22:52:06.0000] <annevk>
MikeSmith: yeah, flawed architecture

[22:52:46.0000] <annevk>
MikeSmith: seems Tanvi is aware of it though so maybe it'll get fixed some day

[22:53:02.0000] <MikeSmith>
annevk: cool, they should give me a bonus in my bug-reporting royalty check for that

[22:55:55.0000] <kochi>
annevk: that exlanation is very understandable

[23:02:20.0000] <TabAtkins>
annevk: Mind switching Compat over to gh-pages? http://www.xanthir.com/b4Zz0 for an easy guide.

[23:02:27.0000] <JakeA>
wanderview: annevk: if the bfcache impl is effectively keeping the page in memory, I wouldn't expect it to fire a fetch event on back/forward

[23:02:29.0000] <TabAtkins>
That way we can look at the spec from github too.

[23:02:43.0000] <annevk>
TabAtkins: it should sync automatically to https://compat.spec.whatwg.org/

[23:02:48.0000] <annevk>
automatically*

[23:03:03.0000] <TabAtkins>
danbeam: You want "[attr], * /deep/ [attr]".

[23:03:12.0000] <TabAtkins>
annevk: Okay, then please link that from the readme. ^_^

[23:04:36.0000] <annevk>
TabAtkins: you can't look at the link at the top of the repo? :p

[23:05:06.0000] <TabAtkins>
Who looks there?

[23:05:50.0000] <annevk>
I hope you're happy

[23:08:39.0000] <TabAtkins>
Thank you :-*

[23:24:22.0000] <annevk>
TabAtkins: at some point we need to work this through too: https://github.com/w3c/resource-timing/issues/27#issuecomment-122189039

[23:24:30.0000] <annevk>
TabAtkins: but I guess HTML first...

[23:24:55.0000] <annevk>
CSS and SVG have some tricky corner cases when it comes to Fetch, though I think most of the infrastructure is in place

[00:13:59.0000] <MikeSmith>
TabAtkins: (if you're still awake & around) I've been asked to do a 30-minute presentation about CSS for a webdev/designer audience, on any specific topic I'd like. At a CSS conference where all ~6-8 or so other speakers are actual web devs/designers who unlike me actually do a lot of day-to-day work using CSS. So if I have to do it I'd like to talk something no other speakers are likely to be covering a

[00:14:05.0000] <MikeSmith>
nd that will be new to the audience.

[00:14:20.0000] <MikeSmith>
TabAtkins: so, given all that, any suggestions?

[00:14:41.0000] <MikeSmith>
"The Dark Side of CSS"

[00:18:01.0000] <MikeSmith>
one thing more near and dear for me is that I think we need to make a new CSS Checker (aka validator) to replace the current Java-based bailing-wire-and-duct-tape one

[00:18:45.0000] <MikeSmith>
and write it in Javascript, using your parser/tokenizer as a start, to run under node.js

[00:19:22.0000] <MikeSmith>
so maybe I could use the opportunity to see if I can get anybody else interested in collaborating on that

[00:20:59.0000] <Ms2ger>
Ew, js

[00:21:12.0000] <Ms2ger>
There's a good Rust CSS parser ;)

[00:29:34.0000] <MikeSmith>
oh hey

[00:29:45.0000] <MikeSmith>
that would be more fun actually

[00:31:09.0000] <MikeSmith>
Ms2ger: did SimonSapin write that?

[00:31:19.0000] <Ms2ger>
Yup

[00:31:32.0000] <MikeSmith>
yeah

[00:31:38.0000] <MikeSmith>
perusing https://github.com/servo/rust-cssparser/commits/master

[00:33:05.0000] <MikeSmith>
this would be a great way for me to learn rust and make something actually useful when doing it

[00:33:17.0000] <SimonSapin>
MikeSmith: feel free to file issues or ping me about this

[00:33:54.0000] <MikeSmith>
SimonSapin: will do

[00:34:43.0000] <MikeSmith>
(btw y'all really want to have a TR link in the description of that repo? "Rust implementation of CSS Syntax Level 3 http://www.w3.org/TR/css-syntax-3/"

[00:35:17.0000] <SimonSapin>
good point

[00:35:50.0000] <MikeSmith>
http://drafts.csswg.org/css-syntax/ I guess

[00:36:39.0000] <MikeSmith>
SimonSapin and TabAtkins btw please consider to stop using http://dev.w3.org/ URLs in CSS drafts

[00:36:59.0000] <MikeSmith>
and just use http://drafts.csswg.org/ URLs instead

[00:37:02.0000] <SimonSapin>
I was gonna say I wish we could pick one. Could it be a redirect?

[00:37:34.0000] <MikeSmith>
SimonSapin: redirect? why not just use http://drafts.csswg.org/css-syntax/ ?

[00:38:11.0000] <SimonSapin>
MikeSmith: I mean, could http://dev.w3.org/csswg/ redirect to https://drafts.csswg.org/ rather than proxy?

[00:38:15.0000] <MikeSmith>
all http://dev.w3.org/csswg URLs are rewrites; reverse-proxying or whatever Apache calls it

[00:38:32.0000] <SimonSapin>
make it HTTP 301’s

[00:38:43.0000] <MikeSmith>
SimonSapin: it could yeah

[00:38:51.0000] <MikeSmith>
I should make it do that

[00:39:03.0000] <SimonSapin>
that will make people use the new URL

[00:39:13.0000] <MikeSmith>
yeah

[00:39:18.0000] <SimonSapin>
I tend to navigate to whatever is in my browser history, and copy/paste whatever is in the URL bar

[00:39:30.0000] <MikeSmith>
yup

[00:39:45.0000] <MikeSmith>
I will tell plinss I'm going to change it to a 301

[00:40:02.0000] <SimonSapin>
make it HTTPS, while you’re at it :)

[00:40:16.0000] <MikeSmith>
at this point it's just an additional point of possible failure that adds nothing except having w3.org in the URL

[00:41:28.0000] <MikeSmith>
I think that dev.w3.org server isn't on the list of servers that the W3C systems team is working on moving to https

[00:41:45.0000] <SimonSapin>
I mean redirect to https://

[00:42:18.0000] <MikeSmith>
ah yeah

[00:42:19.0000] <MikeSmith>
sure

[00:43:19.0000] <MikeSmith>
SimonSapin: so the servo rust parser fully conforms to the current CSS syntax spec?

[00:43:56.0000] <SimonSapin>
it might not be completely up to date

[00:44:18.0000] <Ms2ger>
Variables?

[00:44:57.0000] <MikeSmith>
Ms2ger: you mean it doesn't support CSS Variables yet?

[00:45:18.0000] <Ms2ger>
I don't know

[00:45:26.0000] <MikeSmith>
/me tries to remember if/where CSS Variables have been implemented

[00:45:37.0000] <Ms2ger>
Is there any parser work required for them?

[00:46:00.0000] <MikeSmith>
good question

[00:46:18.0000] <MikeSmith>
/me looks around for a CSS-parser implementor to ask

[00:47:49.0000] <MikeSmith>
y'all know of any other rust-based tools anybody's made for providing the server-side backend of Web app?

[00:48:55.0000] <MikeSmith>
or some kind of existing rust-based http server

[00:49:01.0000] <SimonSapin>
MikeSmith: rust-cssparser is property agnostic, you need to write parsing code for every property you want to support. It implements the Syntax spec and nothing else.

[00:49:17.0000] <Ms2ger>
hyper/iron

[00:49:18.0000] <MikeSmith>
/me finds https://github.com/chris-morgan/rust-http

[00:49:25.0000] <Ms2ger>
rust-http is abandoned

[00:49:30.0000] <MikeSmith>
ah OK

[00:49:34.0000] <SimonSapin>
MikeSmith: try https://github.com/iron/iron

[00:49:39.0000] <MikeSmith>
/me looks

[00:50:11.0000] <MikeSmith>
SimonSapin: ok (about "property agnostic, you need to write parsing code for every property you want to support"

[01:07:19.0000] <kochi>
Is "CSS Custom Properties" a new name for "CSS Variables"?

[01:18:36.0000] <MikeSmith>
kochi: /me doesn't know

[01:20:05.0000] <MikeSmith>
SimonSapin: can rust-cssparser in its current form be feasibly made error-reporting?

[01:20:22.0000] <SimonSapin>
kochi: yes

[01:20:59.0000] <kochi>
SimonSapin: thx, I thought it was once abondoned ;)

[01:55:41.0000] <MikeSmith>
SimonSapin: you saw my question earlier?

[01:55:51.0000] <MikeSmith>
about error reporting?

[02:25:46.0000] <annevk>
MikeSmith++ for redirecting dev.w3.org

[02:54:35.0000] <annevk>
miketaylr: https://twitter.com/compatstandard should perhaps link to the spec?

[02:54:43.0000] <annevk>
miketaylr: although I guess there isn't much of a spec yet

[03:28:04.0000] <smaug____>
/me wonders if dglazkov ended up with the current Custom elements design because running ctors sync was just too hard

[03:28:35.0000] <annevk>
smaug____: part of the problem was that constructors were not a thing

[03:29:07.0000] <annevk>
smaug____: but yes, I think the "invoke callbacks a little later" stems from the invariants breaking trouble

[03:48:13.0000] <annevk>
JakeA: you around?

[03:48:21.0000] <JakeA>
annevk: yep!

[03:48:40.0000] <annevk>
JakeA: in step 2.2 of https://fetch.spec.whatwg.org/#http-fetch why do we disallow a CORS response to a client request?

[03:50:55.0000] <JakeA>
annevk: wanderview asked me this recently & I couldn't remember. It may have been a precaution, but I don't see what it prevents as you could just make a manual response with the same content

[03:52:10.0000] <annevk>
JakeA: I want to change that line to 'if request is a navigation request and response is "opaque"'

[03:52:38.0000] <annevk>
JakeA: although I think that might be covered already by 'request's mode is not "no-cors" and response's type is "opaque".' I'm not entirely sure, since HTML hasn't been updated yet

[03:53:07.0000] <annevk>
(I think a navigation request, by definition, is always with mode "same-origin")

[03:54:31.0000] <JakeA>
agreed. I don't think we'd need to single out 'navigation', even if we did we'd want to ensure other client requests don't get opaque content

[03:56:08.0000] <annevk>
JakeA: well I know for a fact that workers are always "same-origin"

[03:56:17.0000] <annevk>
JakeA: and client is navigation + workers

[03:57:23.0000] <JakeA>
annevk: could it be an "assert" in the spec? (until HTML specifies same-origin for navigations)

[03:58:45.0000] <annevk>
JakeA: I could make it a note for now, I don't really have formal asserts anywhere

[03:59:09.0000] <JakeA>
A note would be good enough

[04:04:25.0000] <annevk>
JakeA: ta

[04:10:28.0000] <annevk>
JakeA: wanderview: https://github.com/whatwg/fetch/commit/1612905aae06fdb912779b308d71bfc13422833f

[04:11:52.0000] <JakeA>
annevk: lgtm

[04:12:59.0000] <annevk>
JakeA: how is cancelation going?

[04:13:56.0000] <annevk>
JakeA: the only new tricky thing I can think of there is being able to cancel "no-cors" stuff and thereby perhaps being able to extract data somehow

[04:14:29.0000] <JakeA>
annevk: Haven't looked at it for a couple of weeks (holiday, then this week), but I was approaching a prototype. Going to stab at it on the flight

[04:14:43.0000] <JakeA>
The plan is to make Promise cancelable, but only by the creator

[04:14:53.0000] <JakeA>
and have CancelablePromise which is cancelable by outsiders

[04:14:59.0000] <annevk>
And you're refcounting?

[04:15:14.0000] <JakeA>
CancelablePromise would have the refcounting

[04:15:34.0000] <annevk>
What would fetch() use?

[04:15:36.0000] <JakeA>
the tough bit, which is still todo, is how to handle promises resolved with promises

[04:15:42.0000] <JakeA>
fetch() would use CancelablePromise

[04:15:52.0000] <JakeA>
(or you could opt into it)

[04:16:13.0000] <JakeA>
fetch(url, {cancelable: true}) perhaps - although I'd rather it was default

[04:16:19.0000] <annevk>
I see, perhaps the solution for "no-cors" is simply that you can't cancel it

[04:16:54.0000] <annevk>
That would certainly be the least leaky

[04:18:04.0000] <annevk>
Although even for CORS that'd mean you could only cancel it once you have seen the headers and followed the redirects...

[04:18:05.0000] <JakeA>
annevk: I was talking to David Benjamin & Ryan Sleevi about it briefly yesterday, they weren't too bothered about it.

[04:18:25.0000] <annevk>
Hmm okay

[04:19:16.0000] <JakeA>
It's not the final say, but we couldn't think of something that'd leak with a partial body

[04:20:28.0000] <annevk>
I'm mostly worried about stuff like `p { content: "Secrets!" } p { content: "no secrets" }`

[04:20:32.0000] <annevk>
and similar things in script

[04:21:00.0000] <JakeA>
Script is running in the context of the page, so you're only shooting yourself in the foot

[04:22:07.0000] <annevk>
Yeah, seems hard to extract data from a script, though we do make exceptions opaque and don't expose comments and such

[04:22:47.0000] <annevk>
Attackers are pretty clever and manage to exploit all kinds of things nobody thought of

[04:23:10.0000] <JakeA>
I didn't know about the exception thing. Are you saying if a no-cors script throws, window.onerror doesn't get a full picture of it?

[04:23:16.0000] <annevk>
correct

[04:23:23.0000] <JakeA>
TIL

[04:23:57.0000] <annevk>
<script> does not check MIME types, so you'd be able to load all kinds of resources and extract data from the exception that way

[04:24:31.0000] <JakeA>
True, certainly for parse errors

[04:24:38.0000] <annevk>
JakeA: if you have time: https://github.com/whatwg/fetch/issues/67

[04:47:24.0000] <SimonSapin>
MikeSmith: at the moment rust-cssparser ignore what the Syntax spec calls "parse errors". But with some work that could be added

[04:58:24.0000] <MikeSmith>
SimonSapin: ok

[05:00:25.0000] <MikeSmith>
SimonSapin: I see the code for BadURL etc, and it wouldn't be much work to add some error-reporting for those which could optionally be switched on by consuming apps that want error reporting

[05:02:17.0000] <SimonSapin>
MikeSmith: Yes, each of Bad*, and after the parser Close* tokens is a parse error, but they don’t represent all parse errors

[05:03:31.0000] <SimonSapin>
I have to double check if the spec ever emits more than one parse error per token. If not, the tokenizer could yield something like (Token, Option<ParseError>) rather than just Token

[05:07:47.0000] <MikeSmith>
SimonSapin: OK

[05:09:12.0000] <MikeSmith>
annevk: square brackets in URL query part or path must be percent-encoded, right?

[05:27:59.0000] <Ms2ger>
TabAtkins, hey, could you have a look at https://github.com/Reviewable/Reviewable/issues/127 ?

[05:45:47.0000] <annevk>
MikeSmith: something around that changed recently

[05:46:53.0000] <annevk>
MikeSmith: I think they must be encoded, but are not by the parser if they aren't

[05:47:43.0000] <MikeSmith>
annevk: ok

[06:47:27.0000] <TabAtkins>
MikeSmith: Variables are impl'd in Firefox and about to be turned on in Chrome.  An earlier (and prefixed >_<) syntax of them is in WebKit.

[06:47:41.0000] <annevk>
MikeSmith: spam https://www.w3.org/Bugs/Public/show_bug.cgi?id=27162#c2

[06:50:23.0000] <TabAtkins>
Ms2ger or MikeSmith: A Syntax-supporting browser doesn't need to do anything special to support Custom Properties.  The actual style system implementation generally does, because it's not used to storing raw tokens or pasting them into other properties at computed-value-time, but at the parsing level they're nothing special.

[07:00:33.0000] <miketaylr>
annevk: cool, will add the link

[07:00:49.0000] <miketaylr>
(and fix the commit thing today hopefully)

[07:01:46.0000] <MikeSmith>
TabAtkins: ok, thanks

[07:02:24.0000] <miketaylr>
oh wait, it looks like it already tweeted.

[07:05:29.0000] <Ms2ger>
"Google is not affiliated with the contents of Chromium Code Reviews or its owners."

[07:05:40.0000] <MikeSmith>
annevk: somebody else already disabled that bug-spammer's account

[07:07:16.0000] <TabAtkins>
Ms2ger: Correct, we're not, Chromium is an open-source project that happens to be mostly worked on by Googlers.

[07:12:03.0000] <MikeSmith>
everybody wants to be like, "Hey *I'm* not the one who made this code-review tool with a really bad UI and user experience."

[07:12:37.0000] <TabAtkins>
It really is the worst.

[07:13:31.0000] <MikeSmith>
yeah I feel genuinely sorry for people who have to use it every day

[07:14:38.0000] <MikeSmith>
but then pretty much all code-review tools that browser projects use are pretty bad as far as the UI and UX

[07:15:13.0000] <MikeSmith>
but that one looks like to was designed by somebody at Oracle, or SAP

[07:24:24.0000] <Domenic>
You can switch to the new UI, it feels less horrible

[07:25:50.0000] <TabAtkins>
Domenic: How?!?

[07:26:04.0000] <Domenic>
TabAtkins: settings, uncheck use legacy UI

[07:26:59.0000] <annevk>
miketaylr: I didn't touch anything related to Twitter, but when I changed the README it did tweet indeed

[07:36:52.0000] <Domenic>
yesss it's coming full circle https://twitter.com/feross/status/621960735401193472

[07:37:42.0000] <Ms2ger>
So the not "deprecated ui" is just "wait forever until everything's loaded client-side"?

[07:38:35.0000] <Domenic>
I think there's a reason it's not on by default.

[07:39:20.0000] <MikeSmith>
choose your poison

[07:42:59.0000] <MikeSmith>
I think tools that people in product-development orgs develop and foist on one another are subconsciously some form of complex passive-aggressive way to try to punish each other

[07:49:30.0000] <jgraham>
MikeSmith: It's not like there are all these great commercial review tool products available

[07:49:48.0000] <jgraham>
The actual state of the nation seems to be "everything sucks in different ways"

[07:50:52.0000] <MikeSmith>
jgraham: true, I guess there's not a big market out there for it with people who have lots of high expectations for it in terms of usability

[07:51:10.0000] <TabAtkins>
It's Better Than Command Line®

[07:51:57.0000] <jgraham>
Well, I think to a certain extent that's untrue

[07:53:09.0000] <jgraham>
People want a specific kind of usability which isn't necessarily the same as for some random content consuming app

[07:53:11.0000] <wanderview>
annevk: is this something that will be fixed in the fetch spec or does it need to go in the other specs? "The underlying assumption here is that all client requests use mode "same-origin", which is currently not explicitly stated for navigation requests."

[07:53:34.0000] <jgraham>
It has to have all the reequired features to make them productive and not get in the way of their prefered workflow

[07:53:39.0000] <annevk>
wanderview: needs to be fixed in HTML

[07:53:47.0000] <annevk>
wanderview: specifically its navigate algorithm

[07:54:09.0000] <wanderview>
/me doubts we set event.request.type correctly

[07:54:40.0000] <annevk>
wanderview: you mean context?

[07:55:18.0000] <wanderview>
annevk: sorry... RequestMode

[07:55:49.0000] <wanderview>
I'll have to look at what we do... we seem to set no-cors correctly for cross origin stuff... just wondering if we set same-origin in the right places

[07:58:04.0000] <smaug____>
MikeSmith: designing a good code review tool seems to be very very hard, because people have their own habits for reviewing code

[07:58:11.0000] <smaug____>
one tool may not fit to all

[08:20:53.0000] <wanderview>
annevk: do you really think get-with-bodies is worth it if you're never going to get the right caching semantics anyway?  might as well just require post to be used

[08:21:27.0000] <annevk>
wanderview: it didn't seem to be about caching so much

[08:21:46.0000] <wanderview>
annevk: one of the whole complaints about post was that it broke caching, though

[08:22:09.0000] <wanderview>
the other complaint about post is that "its not theoretically pure to the REST concept"... which I don't really rate as a concern

[08:24:36.0000] <annevk>
wanderview: I think the main point is that HTTP allows it while we don't

[08:24:40.0000] <annevk>
wanderview: at least for me

[08:25:02.0000] <annevk>
wanderview: that seems worth sorting out a definitive answer to at some point, but likely not this year

[08:25:30.0000] <annevk>
(but others are welcome to prioritize differently of course and sort it out)

[08:26:51.0000] <wanderview>
annevk: does it really allow GET bodies?  the spec he linked to says "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."

[08:27:20.0000] <annevk>
wanderview: none of that says it's disallowed

[08:27:49.0000] <annevk>
wanderview: would have to be a quite literal statement or grammar production

[08:28:04.0000] <annevk>
"no defined semantics" means nothing, since some protocol on top of HTTP might give it semantics

[08:28:55.0000] <wanderview>
ok... I just don't see the advantage of using GET over POST if you're not getting caching semantics anyway

[08:29:17.0000] <wanderview>
anyway, I have to run to meet someone for lunch... later

[12:18:44.0000] <danbeam>
TabAtkins: * /deep/ [attr] doesn't work if the first level of elements has [attr]

[13:19:34.0000] <TabAtkins>
danbeam: That's why I said `[attr], * /deep/ [attr]`.  (It's unfortunate we don't have the ability to do "self and combinator".)


2015-07-18
[19:04:12.0000] <MikeSmith>
does anybody know what the proper mechanism is for reporting bugs in https://developers.google.com content

[19:05:20.0000] <MikeSmith>
https://developers.google.com/structured-data/site-name has an example that suggests using <link rel="canonical" href="https://example.com/" itemprop="url"> which violates the "A link element must have either a rel attribute or an itemprop attribute, but not both." requirement in the HTML spec https://html.spec.whatwg.org/multipage/semantics.html#the-link-element

[19:37:40.0000] <JonathanNeal>
Is this on track for spec? https://lists.w3.org/Archives/Public/www-style/2014Jul/0315.html

[19:37:56.0000] <JonathanNeal>
translate, rotate, and scale properties.

[19:46:10.0000] <astearns>
JonathanNeal: yes, we're planning on adding that to the next level of CSS Transforms

[19:47:33.0000] <astearns>
http://drafts.csswg.org/css-transforms-2/

[19:48:55.0000] <JonathanNeal>
astearns: That’s what I wanted. I’m working on a PostCSS plugin for it.

[19:49:58.0000] <JonathanNeal>
Here is the work I have started https://github.com/jonathantneal/postcss-transform-shortcut

[20:01:30.0000] <JonathanNeal>
astearns: so `translate: 10px 10px;` is the same as `transform: translate3d(10px, 10px, 0px)` ?

[20:02:26.0000] <JonathanNeal>
I’m basing this off “The translate property accepts 1-3 values, each specifying a translation against one axis, in the order X, Y, then Z. Unspecified translations default to 0px.” I presume this means all three axis are automatically declared, defaulting to `0px`.

[20:15:24.0000] <astearns>
JonathanNeal: that sounds correct to me, but I'd defer to more transform-oriented people

[01:01:56.0000] <therophyte>
VER

[02:03:41.0000] <annevk>
philipj: so basically, define "unloading document cleanup steps" to run https://fullscreen.spec.whatwg.org/#unfullscreen-a-document right?

[02:08:54.0000] <annevk>
/me proceeds with that assumption

[02:09:14.0000] <annevk>
philipj: if you find new issues, could you please file new GitHub issues?

[02:09:37.0000] <annevk>
philipj: having to deal with Bugzilla less is starting to feel like a plus

[06:47:41.0000] <mikec>
What functionality is replacing DocumentType.entities these days? i.e. where is the list of entities recognized by a parser "stored"? Is it just the fixed list at http://dev.w3.org/html5/html-author/charref ?

[07:03:57.0000] <gsnedders>
mikec: in HTML, there's been a fixed list for years (okay, it occasionally get ammended, but there's no point in exposing the list anyway)

[07:04:19.0000] <gsnedders>
mikec: in XML, no UA to my knowledge loads external entities, so there's no that much use to the API either

[07:05:30.0000] <MikeSmith>
mikec: yeah the list of character references that HTML parsers must support is in the HTML spec

[07:08:08.0000] <mikec>
MikeSmith: thanks

[07:10:45.0000] <MikeSmith>
gsnedders: did you see https://github.com/w3c/web-platform-tests/issues/1999

[07:12:39.0000] <MikeSmith>
apparently the use of data: URIs in wpt tests is blocking somewhat the Blink team's efforts to integrate the wpt test suite into their CI

[07:13:10.0000] <MikeSmith>
and the html5lib tests are one place where they're used a lot

[07:13:39.0000] <gsnedders>
MikeSmith: that's jgraham's doing

[07:13:46.0000] <MikeSmith>
ok

[07:14:06.0000] <gsnedders>
MikeSmith: pretty sure I did the internal review of tham when he wrote them, but that was Opera 11 days.

[07:14:07.0000] <MikeSmith>
well I been wondering if the data URI instances in the wpt html5lib tests could be replaced with <img srcdoc>

[07:14:23.0000] <MikeSmith>
yeah I guess it's been a while

[07:14:35.0000] <gsnedders>
from memory there were data URI versions and document.open/write/close versions?

[07:14:44.0000] <MikeSmith>
oh

[07:14:53.0000] <gsnedders>
the latter should work at least

[07:15:02.0000] <gsnedders>
also I should find out what gate I'm meant to be going to

[07:15:16.0000] <MikeSmith>
well jgraham says at https://github.com/w3c/web-platform-tests/issues/1999#issuecomment-121080384 "I welcome PRs to change these tests to not use data: URIs (but in at least some cases I expect that to be difficult e.g. the html5lib tests are based around loading a document generated in content using the regular HTML parser; I'm not sure how else to do that)"

[07:15:35.0000] <gsnedders>
idk!

[07:15:54.0000] <gsnedders>
I certainly remember seeing some conversion of them to use document.open/write/close

[07:16:17.0000] <gsnedders>
But yeah, I only maintain the actual tests in our weird test format. I've not handled any browser runner in years.

[07:16:35.0000] <gsnedders>
Anyhow, yes, gate hunting.

[07:16:45.0000] <gsnedders>
Things to do, places to fly, etc.

[07:18:24.0000] <MikeSmith>
hai

[07:18:29.0000] <MikeSmith>
have fun

[07:22:47.0000] <gsnedders>
"Please wait", apparently. Oh well.

[07:23:00.0000] <gsnedders>
(Gate due to be announced in -7 minutes.)

[07:30:31.0000] <MikeSmith>
if you're at Heathrow the thing they do there of not announcing gates ahead of time and making you wait in the human-corral area is real innovation in making the most hostile user experience possible

[07:31:18.0000] <MikeSmith>
"Just when you thought the airport experience couldn't be anyway worse, we're still busy figuring out new ways!"

[07:31:46.0000] <gsnedders>
This is T3. So this is even worse.

[07:32:43.0000] <gsnedders>
For some reason I doubt we're leaving in 13 minutes.

[07:32:44.0000] <MikeSmith>
it's like a microcosm of all the worst aspects of British culture

[07:33:06.0000] <MikeSmith>
enjoy the ambience in the mean time

[07:33:22.0000] <MikeSmith>
soak in the full experience

[07:33:56.0000] <gsnedders>
yay, a gate!

[07:34:00.0000] <gsnedders>
/me scurries off

[07:40:29.0000] <gsnedders>
still another twenty minutes…

[09:22:40.0000] <jgraham>
MikeSmith, gsnedders: Yes, there are document.write versions, but that's an entirely different codepath, so I wouldn't run *only* those version

[09:22:44.0000] <jgraham>
s

[09:22:56.0000] <jgraham>
<iframe srcdoc> might be acceptable if that's same origin

[11:32:58.0000] <wanderview>
Ms2ger: if you have time, could you make me an account on wiki.whatwg.org with the username wanderview?  I want to collaborate on the SW related pages... thanks!

[11:40:18.0000] <gsnedders>
jgraham: it should be the same codepath in the parser, no? or is it that different because of the re-entrant stuff?

[12:53:21.0000] <jgraham>
gsnedders: Certainly I have managed to find bugs using document.write that the other approach didn't. That's why they're seperate tests.

[12:58:59.0000] <smaug____>
writing tests for document.write? including also document.open()/close() behavior?

[12:59:14.0000] <smaug____>
/me assumes tons of differences between browser engines

[13:01:55.0000] <gsnedders>
smaug____: I'm talking about just using open/write/close triplets to test the parser, really without any of the re-entrant fun

[13:15:11.0000] <smaug____>
oh, I wasn't even thinking re-entrancy

[13:15:42.0000] <smaug____>
but all the handling with session history and global scope and what not, when document.open/write is used after load event dispatch

[13:42:50.0000] <jgraham>
Yeah, that stuff is an interop wasteland

[14:04:12.0000] <gsnedders>
oh, that sort of stuff

[14:04:34.0000] <gsnedders>
well yeah, the html5lib test conversions only really test what the parser does, not that nightmare


2015-07-19
[17:47:07.0000] <MikeSmith>
wanderview: I can make you an account

[17:50:03.0000] <MikeSmith>
wanderview: if you want a different username just lemme know what other one you want

[02:09:10.0000] <Ms2ger>
Someone specced #rrggbbaa?

[06:47:24.0000] <wanderview>
MikeSmith: thanks!

[10:44:34.0000] <annevk>
Ms2ger: TabAtkins did I think

[10:44:45.0000] <annevk>
Ms2ger: also #rgba

[11:02:01.0000] <TabAtkins>
Yeah, in Color 4

[11:09:15.0000] <TabAtkins>
Ms2ger: Feel free to implement in ff, it's a trivial patch. 😀

[11:11:23.0000] <TabAtkins>
JonathanNeal: Yes that's correct (re translate)


2015-07-20
[04:17:58.0000] <howdoi>
howdy?

[04:18:36.0000] <howdoi>
I made a node module for TC39 members list -> http://git.io/tc39-members seeking help to verify the list and added the twitter handles as well, thanks.

[04:18:37.0000] <howdoi>
 

[04:19:21.0000] <howdoi>
/cc @Domenic @arv

[05:42:22.0000] <Domenic>
howdoi: TC39 members are companies. There is no fixed list of who those companies send to represent them at each meeting.

[05:43:16.0000] <Domenic>
howdoi: your list looks several years out of date in terms of who attends meetings these days.

[05:43:25.0000] <Domenic>
check the meeting notes if that's what you're interested in.

[05:45:02.0000] <howdoi>
Domenic: yup, I'm aware that it's outdated, so seeking help :) Didn't find Jafar Husain from Netfilx in the list either, any other way then checking the notes, I went through the github org and there are only 8 members there.

[05:45:15.0000] <Domenic>
that's what i'm saying, there is no list

[05:45:19.0000] <Domenic>
there is just a list of companies

[05:45:48.0000] <Domenic>
if your repo is called tc39-members it should be a list of companies

[05:45:57.0000] <Domenic>
if it is called tc39-attendees-of-last-meeting it can be people

[05:48:59.0000] <howdoi>
Domenic: oh, hmm, so people are invited? I saw an invite that was at Redmond Microsoft

[05:53:02.0000] <howdoi>
Domenic: I shall divide the json to attendess and companies, makes sense?

[05:53:38.0000] <Ms2ger>
So why are you creating this list?

[05:57:54.0000] <howdoi>
Data!

[05:58:01.0000] <howdoi>
Raw Data!

[05:58:13.0000] <Ms2ger>
So why are you creating this list?

[06:01:20.0000] <annevk>
Domenic: can't just be companies though

[06:01:26.0000] <annevk>
Domenic: say, Brendan Eich

[06:04:10.0000] <howdoi>
^_^

[06:18:25.0000] <annevk>
MikeSmith: should have some kind of style guide for specs

[06:18:34.0000] <annevk>
MikeSmith: I think the W3C has one, but it's not a wiki page

[06:18:38.0000] <annevk>
MikeSmith: so kinda blows

[06:20:41.0000] <MikeSmith>
annevk: yeahwe need one. So I'll work on making one that doesn't blow.

[06:21:00.0000] <Domenic>
howdoi: I don't really care what you do with this list, since it's useless and doesn't reflect reality

[06:21:49.0000] <MikeSmith>
annevk: should we make a github repo for it, or you think a wiki is better?

[06:22:15.0000] <annevk>
MikeSmith: I guess that's up to you, whatever you like better

[06:22:37.0000] <MikeSmith>
ok

[06:23:14.0000] <MikeSmith>
I don't like wikis so the answer to that is easy

[06:23:28.0000] <annevk>
MikeSmith: heh, I suggest "style" as a shortname

[06:23:44.0000] <annevk>
but I shouldn't be bikeshedding about this

[06:24:14.0000] <MikeSmith>
will create a "style" repo today

[06:24:43.0000] <MikeSmith>
shorter short names are better

[06:26:53.0000] <howdoi>
Domenic: heh heh, thanks :)

[06:33:58.0000] <izhak>
Hi, guys! I have a very complex bad written code, a mess of html, javascript and svg (d3). When svg gets redrawn a page gets scrolled. How can I debug this, I just can't figure out how to learn why it gets scrolled.

[06:35:08.0000] <howdoi>
izhak: you must ask at #javascript

[06:37:02.0000] <izhak>
howdoi: oh, right. forgot about it :) whatwg is great anyways)

[06:37:49.0000] <howdoi>
:}

[06:50:28.0000] <gsnedders>
annevk, howdoi: http://www.ecma-international.org/memento/members.htm

[06:50:53.0000] <gsnedders>
in principle all ECMA members are companies or NPOs

[06:51:14.0000] <gsnedders>
Quite in what capacity Brendan is there… well… :)

[06:51:24.0000] <Domenic>
He was voted as like permanent guest or something

[06:51:28.0000] <annevk>
gsnedders: I guess TC39 gets to make special cases since Ecma (not ECMA) exists mostly due to it

[06:51:48.0000] <annevk>
Ecma, but ECMAScript, never gets old

[06:51:57.0000] <howdoi>
gsnedders: nice!

[06:52:24.0000] <annevk>
continues to exist*

[06:53:03.0000] <Domenic>
https://github.com/rwaldron/tc39-notes/blob/6d91c21077ea8b0eb0e9eb7e262572c23374f8c7/es6/2014-04/apr-9.md#rftg-item

[06:53:08.0000] <howdoi>
gsnedders: https://github.com/hemanth/tc39-members/issues/1 will be taken care of.

[06:53:53.0000] <annevk>
Which I think is somewhat stupid. I don't really see a good reason why'd we pay 10k a year to yet another SDO when there's already quite a few to pick from

[06:54:12.0000] <howdoi>
Domenic: yeah, went through the notes, as well as https://github.com/tc39

[06:55:11.0000] <Ms2ger>
How about we move JS to Khronos

[06:55:31.0000] <MikeSmith>
I second that motion

[06:58:46.0000] <MikeSmith>
annevk: speaking of fun, I find https://www.w3.org/2001/06/manual/ and see that it's under ye olde W3C Document License so if I start from that I'll get to deal with the Good Times of needing to talk with others about re-licensing or whatever

[06:59:01.0000] <MikeSmith>
might be easier to just start from scratch

[06:59:12.0000] <Ms2ger>
Might get better quality too

[06:59:17.0000] <MikeSmith>
heh

[06:59:59.0000] <MikeSmith>
well if I do that then I'll probably get "Y U NO USE WE ALREADY MADE ONE??!!"

[07:00:37.0000] <MikeSmith>
fun world to work in where trying to do even the simplest things are fraught

[07:00:42.0000] <MikeSmith>
and I do mean fraught

[07:01:20.0000] <annevk>
Nothing quite compares to public benefit organizations locking everything away from the public. Though a public benefit organizations whose agenda is set by corporations is bound to be somewhat fraud.

[07:02:23.0000] <annevk>
I guess fraught is a better term.

[07:05:15.0000] <MikeSmith>
annevk: I get your message. I hear you saying, "Let's go full fraught [fraud] with this and author the source in MS Word and publish it as PDF and ask jorendorff convert it to HTML."

[07:05:23.0000] <MikeSmith>
and I like your thinking

[07:05:47.0000] <gsnedders>
Ms2ger: and then call it KhronosScript?

[07:05:56.0000] <gsnedders>
Or maybe KHRONOScript?

[07:06:07.0000] <MikeSmith>
gsnedders: solid gold

[07:06:12.0000] <gsnedders>
annevk: bah, until 1994 is was ECMA!

[07:06:17.0000] <gsnedders>
/me ignores the fact he was two then

[07:06:19.0000] <MikeSmith>
magic brainstorming happening here

[07:06:35.0000] <jgraham>
Oh. It took me like 10 years to realise that ISO is a pun

[07:07:00.0000] <jgraham>
I guess there's just nothing funny about ISO that suggests someone had a sense of humor

[07:07:03.0000] <Ms2ger>
It is?

[07:07:18.0000] <MikeSmith>
jgraham: dramatic irony

[07:07:43.0000] <annevk>
slowclaps for MikeSmith & gsnedders

[07:07:45.0000] <jgraham>
Well I assume it comes from the Greek, as in isobar

[07:08:41.0000] <annevk>
/me had to look at https://en.wiktionary.org/wiki/isobar for that

[07:09:53.0000] <jgraham>
https://en.wiktionary.org/wiki/Category:English_words_prefixed_with_iso-

[07:11:55.0000] <annevk>
Maybe KHRONOSScript can introduce Object.iso() to finally settle object comparison once and for all

[07:12:44.0000] <MikeSmith>
haha

[07:13:07.0000] <gsnedders>
But then we'll need an Object.khronos() when the iso decide to (mostly) republish it

[07:13:59.0000] <MikeSmith>
nice

[07:14:26.0000] <MikeSmith>
this channel achieves

[07:14:34.0000] <MikeSmith>
intransitively

[07:15:07.0000] <gsnedders>
and the WHATWG rewrite will just get rid of all of them because none of them are interoperable or relied on by web content

[07:44:09.0000] <philipj>
annevk: are you planning to move to GitHub only for Fullscreen?

[07:47:55.0000] <annevk>
philipj: yeah

[07:47:57.0000] <annevk>
philipj: all specs

[07:48:35.0000] <annevk>
philipj: but I don't really want to move Bugzilla all at once since that creates way too much noise and is not really beneficial, so instead I just encourage creating new issues in GitHub

[07:48:56.0000] <philipj>
annevk: yep, mass moves aren't much fun

[08:28:29.0000] <gsnedders>
jgraham: https://pypi.python.org/pypi/pytest-expect/0.9 now exists, which should in future make it easy to have test expectations for html5lib

[08:46:20.0000] <gsnedders>
jgraham: https://pypi.python.org/pypi/pytest-expect/0.9 now exists, which should in future make it easy to have test expectations for html5lib

[08:46:33.0000] <Ms2ger>
You said that

[08:46:56.0000] <gsnedders>
yeah, something weird with irssi and ssh connections dying

[08:47:05.0000] <gsnedders>
:(

[08:47:19.0000] <gsnedders>
miketaylr: I'd totally missed you moving to Mozilla! :)

[08:47:32.0000] <Ms2ger>
He did?

[08:47:46.0000] <miketaylr>
ha

[08:48:21.0000] <miketaylr>
it's only been ~2 years

[08:51:30.0000] <jgraham>
Change your name to mike-wait-what-he-works-for-Mozilla-now-why-did-no-one-tell-me-taylr

[08:52:17.0000] <miketaylr>
mike-woulda-been-fired-from-opera-eventually-probably-taylr

[09:05:16.0000] <espadrine>
wait, opera still exists?

[09:05:26.0000] <espadrine>
</joke>

[09:07:34.0000] <gsnedders>
how-many-web-evanglists-are-left-anyway

[09:08:20.0000] <annevk>
don't let JakeA hear you say evengalist

[09:09:27.0000] <jgraham>
/me imagines miketaylr on TV trying to raise a million dollars for the church of the web

[09:10:05.0000] <mounir>
tobie: yt?

[09:10:13.0000] <tobie>
yes

[09:10:21.0000] <tobie>
(surprisingly given the heat)

[09:10:30.0000] <mounir>
tobie: you know about respec, don't you?

[09:11:00.0000] <tobie>
mounir: that sounds like a trick question

[09:11:15.0000] <mounir>
tobie: I'm wondering how I can linkify a constructor for an interface

[09:11:17.0000] <tobie>
mounir: to which I should probably answer: "no."

[09:11:41.0000] <mounir>
tobie: you must know :)

[09:11:45.0000] <tobie>
mmm.

[09:13:15.0000] <tobie>
let me check

[09:15:08.0000] <Ms2ger>
Use bikeshed

[09:15:40.0000] <mounir>
Ms2ger: thanks for the help

[09:15:57.0000] <mounir>
:)

[09:16:17.0000] <Ms2ger>
I'm very helpful :)

[09:16:21.0000] <Ms2ger>
Just not in the short term

[09:16:44.0000] <mounir>
Ms2ger: that spec just moved away from anolis to respec

[09:16:53.0000] <mounir>
I don't think moving to bikeshed is an option :)

[09:16:57.0000] <Ms2ger>
Why in the world would you do that

[09:16:58.0000] <tobie>
mounir: doc is here: https://www.w3.org/respec/examples/webidl-contiguous.html#unsupported

[09:17:04.0000] <tobie>
https://www.w3.org/respec/examples/webidl-contiguous.html

[09:18:25.0000] <mounir>
tobie: I can't find how to link to the constructor

[09:19:01.0000] <tobie>
mounir: I'm checking for you.

[09:19:30.0000] <mounir>
I tried usind "Interface" and "Constructor"

[09:20:09.0000] <mounir>
tobie: don't waste your time on that, I'm sure I can live without the linkification

[09:23:31.0000] <tobie>
mounir: ping jyasskin

[09:23:56.0000] <annevk>
you moved from anolis to respec o_O

[09:24:38.0000] <mounir>
annevk: not me, that spec

[09:24:46.0000] <jyasskin>
tobie: I'll be available in ~10 min

[09:24:49.0000] <annevk>
that spec is pretty silly

[09:25:04.0000] <mounir>
you don't even know which spec it is yet :D

[09:25:39.0000] <annevk>
not sure that matters :-P

[09:25:52.0000] <tobie>
jyasskin: cool. mounir is asking about linking constructors to their definition with Respec.

[09:32:29.0000] <jyasskin>
mounir: That's not done yet: https://github.com/w3c/respec/issues/394

[09:33:09.0000] <mounir>
jyasskin: thanks :)

[09:33:20.0000] <jyasskin>
Patches welcome? ;-)

[09:33:27.0000] <jyasskin>
Sorry :)

[10:02:48.0000] <Domenic>
annevk: https://github.com/whatwg/url/issues/49 seems kind of lame; there should be tests for host/hostname too

[10:05:33.0000] <annevk>
yeah, it's not clear they need to be part of the parsing tests though

[10:10:51.0000] <annevk>
MikeSmith: when I load https://www.w3.org/Bugs/Public/buglist.cgi?component=Fullscreen&product=WebAppsWG&resolution=--- I get "There was an error sending mail from 'bugzilla' to 'arun⊙mc': no sender"

[10:11:18.0000] <annevk>
MikeSmith: with a traceback too...

[10:11:22.0000] <Domenic>
annevk: seems convenient if they were; there's columns and everything for the components :P

[10:11:49.0000] <annevk>
Domenic: yeah, could be patched pretty trivially if someone was up to it

[10:11:59.0000] <Domenic>
Sebmaster ^

[10:12:11.0000] <Domenic>
:P

[10:12:48.0000] <Domenic>
#serviceworker is not the conversational utopia i was promised on twitter. just saying.

[10:12:51.0000] <Sebmaster>
:<

[10:13:19.0000] <MikeSmith>
annevk: looking now

[10:13:32.0000] <MikeSmith>
annevk: yeah same here

[10:14:08.0000] <Sebmaster>
I have a much bigger problem with the testability of tr46

[10:14:12.0000] <Sebmaster>
:/

[10:14:26.0000] <Domenic>
right that -_-

[10:18:03.0000] <MikeSmith>
annevk: pinged glob on #qa-bugzilla

[10:30:58.0000] <annevk>
Domenic: heh

[10:31:12.0000] <annevk>
Sebmaster: what's the problem?

[10:31:30.0000] <annevk>
Sebmaster: we can talk to Mark if we need something changed

[10:31:53.0000] <annevk>
Sebmaster: feel free to file TR46 issues against whatwg/url

[10:32:03.0000] <annevk>
Sebmaster: so we can track them somewhat more visibly

[10:32:25.0000] <Sebmaster>
annevk: the available test data is weird

[10:32:48.0000] <Sebmaster>
I have no idea if it's idna2003, idna2008 or tr46 data...

[10:33:57.0000] <annevk>
hmm

[10:34:20.0000] <annevk>
could also file a bug against web-platform-tests to get those tests integrated into the URL tests somehow

[10:34:59.0000] <Sebmaster>
That'd be sweet

[10:35:39.0000] <Sebmaster>
Like... I pass a lot of them, but some just reference stuff which is only checked in idna2008 as far as I know

[10:49:53.0000] <annevk>
Do it and copy me I guess, hopefully I'll get to it one day

[10:53:13.0000] <MikeSmith>
annevk: bugzilla problem seems to have become worse

[10:53:23.0000] <MikeSmith>
I've alerted the systems team

[10:57:20.0000] <TabAtkins>
mounir: Which spec is it? I can be induced to do Bikeshed conversions as long as the spec isn't too long.

[10:58:10.0000] <mounir>
TabAtkins: the editors just picked respec

[10:58:20.0000] <mounir>
I doubt they will be willing to switch to bikeshed

[10:58:24.0000] <TabAtkins>
mounir: You didn't answer my question. ^_^

[10:58:51.0000] <mounir>
TabAtkins: presentation api

[10:58:58.0000] <TabAtkins>
kk, thx

[11:02:11.0000] <webzen>
hi

[11:02:14.0000] <webzen>
es6 module question please  http://laravel.io/bin/321N2

[11:44:45.0000] <webzen>
es6 help please ?  http://laravel.io/bin/d9L1w

[11:56:15.0000] <caitp>
i don't understand the question

[15:01:34.0000] <gsnedders>
oh blargh, test generation order in html5lib in non-deterministic, and because expected values depend on node id which for generators is just iteration number… ;_;

[15:17:30.0000] <roc>
hmm

[15:17:45.0000] <roc>
Chrome really doesn't support 'background-image' on <img>?

[15:41:18.0000] <Yay295>
Are JS events like window.onload considered part of the HTML standard?

[15:54:16.0000] <annevk>
Yay295: yes

[15:54:28.0000] <annevk>
Yay295: though onload is an event handler, load is the event

[16:03:29.0000] <Yay295>
annevk: thanks


2015-07-21
[18:38:02.0000] <MikeSmith>
w3c bugzilla has been updated to v5.0

[18:38:15.0000] <MikeSmith>
if anybody notices problems with it please lemme know

[18:39:45.0000] <MikeSmith>
biggest new feature appears to be ability to tag comments https://www.bugzilla.org/releases/5.0/release-notes.html#feat_comment_tags

[18:42:45.0000] <MikeSmith>
plus the "never email me about this bug" option

[19:36:19.0000] <jakesyl>
  Hello, I'm working on a website and would like to make a login like this: https://accounts.google.com/ServiceLogin?hl=en&continue=https://www.google.com/#identifier (with the box) any idea how to do this?

[19:47:20.0000] <Yay295>
jakesyl: Do you mean you want to use a Google log-in, or do you want to log-in with your own accounts, but make it look like Google's?

[19:51:47.0000] <jakesyl>
make it look like googles

[19:52:24.0000] <Yay295>
What do you need help with? It's pretty much just a white box.

[19:53:05.0000] <jakesyl>
here's what  I have so far: https://gist.github.com/jakesyl/7c81dc31640068068775 I'm working on this right now: https://jsfiddle.net/f780xcs3/ but nothings showing up

[19:53:12.0000] <jakesyl>
The canvas face thing

[19:55:24.0000] <Yay295>
Why are you using a canvas?

[19:55:52.0000] <jakesyl>
to make that face thing

[19:57:10.0000] <Yay295>
You don't need a canvas for that.

[19:57:20.0000] <jakesyl>
hmm, how do i do it then

[19:57:43.0000] <Yay295>
Try doing what Google did. "border-radius: 50%;"

[19:59:47.0000] <jakesyl>
for the....

[20:00:19.0000] <jakesyl>
oh cool!

[20:01:08.0000] <jakesyl>
so how do I make one overlay the other

[20:02:31.0000] <Yay295>
HTML is read top to bottom. Things declared after other things get put on top.

[20:03:46.0000] <Yay295>
You could also use the CSS 'z-index' property.

[20:05:11.0000] <jakesyl>
wait so on googles page what is this for: <canvas id="canvas" class="circle" width="96" height="96"></canvas>

[20:07:15.0000] <Yay295>
I don't see a canvas element when I visit that page. Google must be sending us slightly different pages for some reason.

[20:09:10.0000] <jakesyl>
hmm

[21:26:59.0000] <MikeSmith>
astearns: FYI https://twitter.com/sideshowbarker/status/623347810457358336

[21:27:06.0000] <MikeSmith>
astearns: I realize this isn't your department at all but any guidance or suggestions for who to talk with would be appreciated.

[21:28:26.0000] <astearns>
MikeSmith: I have a couple DW contacts, I'll see who I can send your way

[21:28:46.0000] <MikeSmith>
astearns: thanks, much appreciated

[21:29:08.0000] <MikeSmith>
astearns: Dunno if you know this feature but apparently Dreamweaver (CS6 at least; I don't user Dreamweaver and don't know about versions) has some feature where it will send a document to the (legacy) W3C Validator and some UI for displaying the results

[21:30:02.0000] <astearns>
ah, I didn't know. I've never been a DW user :)

[21:30:15.0000] <MikeSmith>
heh

[21:31:12.0000] <MikeSmith>
well what happened is, since last week, basically I'm taking all requests for HTML5 documents sent to the legacy validator and auto-redirecting them to the Nu HTML Checker https://validator.w3.org/nu/

[21:31:57.0000] <MikeSmith>
if DW is expecting the results in some format that's different from what I'm sending back now, I can try to have the Nu checker send it in that expected format

[21:32:33.0000] <astearns>
or we could update to the new address and format

[21:32:49.0000] <MikeSmith>
yeah I would prefer that

[21:34:03.0000] <astearns>
the 'creative cloud' aspect is supposed to make it easy to update things like this, but I expect there will be a legacy tail where we'd like the old format :)

[21:37:27.0000] <MikeSmith>
yeah

[21:37:46.0000] <MikeSmith>
I don't like breaking things that people depend on

[21:38:02.0000] <MikeSmith>
but on the other hand sometimes you can't know what will break until you break it

[21:45:08.0000] <astearns>
MikeSmith: I've blasted everyone I know on the DW team with your contact info and summary of the issue above

[21:46:40.0000] <MikeSmith>
astearns: coolーthanks much

[22:21:22.0000] <jakesyl>
is this a common error: http://imgur.com/G8THmEG and how do i fix it?

[22:36:49.0000] <Domenic>
Anyone have the email where Boris and annevk work out the custom elements callbacks attached/detached thing?

[22:37:28.0000] <Domenic>
Found it https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0517.html

[01:19:39.0000] <howdoi_>
gsnedders: Fixed it, so it lists out only the companies for now https://github.com/hemanth/tc39-members

[01:19:47.0000] <howdoi_>
thanks.

[02:09:56.0000] <Ms2ger>
  bring back to life:

[02:09:56.0000] <Ms2ger>
  XForms Working Group

[02:19:50.0000] <MikeSmith>
Ms2ger: yeah I encourage y'all to comment on that please

[02:20:02.0000] <MikeSmith>
as in, say No

[02:21:44.0000] <MikeSmith>
there was an XForms WG in plh's domain for years that was doing nothing and he tried to shut it down for a long time and finally succeeded

[02:22:07.0000] <Ms2ger>
I would suggest that, but it'll happen anyway, and most likely people will start wasting dbaron's time trying to get him to change his vote

[02:22:18.0000] <MikeSmith>
ok

[02:23:19.0000] <Ms2ger>
I have basically zero confidence in feedback like that being paid attention to

[02:23:32.0000] <MikeSmith>
oh it's paid attention to

[02:23:44.0000] <MikeSmith>
especially when I amplify it

[02:24:07.0000] <MikeSmith>
but if no AC reps speak up I have nothing to amplify

[02:24:57.0000] <MikeSmith>
I already stalled those charters from going out to the AC to begin with because I insisted that none of those groups be rechartered as Member-only

[02:24:59.0000] <jgraham>
Ms2ger: Oh, you mean outside people?

[02:25:13.0000] <MikeSmith>
originally at least

[02:25:21.0000] <jgraham>
MikeSmith: What is this, 1998?

[02:25:34.0000] <MikeSmith>
yeah, seriously

[02:25:40.0000] <Ms2ger>
jgraham, XML people

[02:26:38.0000] <MikeSmith>
at least make I do think it's worth making the comment "none of this should be going into

[02:27:07.0000] <MikeSmith>
* "none of this work should be getting done under any assumption that it will get implemented in browsers"

[02:27:20.0000] <jgraham>
I'm struggling to imagine anyone who works on Gecko arguing with "we have no intention of implementing XForms, and feel it's a distraction from the real and urgent needs of the web"

[02:27:30.0000] <MikeSmith>
which kinda should make anybody then ask why it's being done at the W3C at all, and that would be a very good question

[02:27:36.0000] <Ms2ger>
Yeah, dbaron already said that

[02:28:07.0000] <jgraham>
Ms2ger: Pointer?

[02:28:10.0000] <Ms2ger>
MikeSmith, last I checked, there was an oil industry group at w3c, so I doubt that says much :)

[02:28:19.0000] <Ms2ger>
"(My inclination is at minimum to explicitly abstain, with comments

[02:28:19.0000] <Ms2ger>
that they shouldn't expect browser implementation.)"

[02:28:26.0000] <Ms2ger>
On m.d.platform

[02:28:52.0000] <jgraham>
Oh, I ignored that because it said "XML Group activity", it seems

[02:31:44.0000] <MikeSmith>
these groups are basically just a kind of pollution at this point

[02:32:11.0000] <MikeSmith>
I wish more AC reps would say stuff like that rather than just not commenting at all or abstaining

[02:32:23.0000] <smaug____>
what is the reason to try to bring XForms back to life?

[02:32:49.0000] <MikeSmith>
smaug____: beacuse there are some diehards that want to keep working on it

[02:33:08.0000] <MikeSmith>
I think it's fine if they do, but that's what we have Community Groups for

[02:33:13.0000] <smaug____>
Pemberton + insurance companies ?

[02:33:20.0000] <Ms2ger>
Why not ECMA?

[02:33:39.0000] <MikeSmith>
I would love to gift the XForms stuff to ECMA

[02:33:48.0000] <MikeSmith>
or Oasis or somewhere

[02:33:51.0000] <Ms2ger>
How about xml core? :)

[02:34:23.0000] <MikeSmith>
zcorpan still gets some productive stuff done in xml core or somewhere

[02:34:32.0000] <MikeSmith>
but I don't know if he plans to keep doing that

[02:34:39.0000] <Ms2ger>
Really?

[02:35:20.0000] <MikeSmith>
he worked on the spec for the XML stylesheet processing instruction at least

[02:35:49.0000] <Ms2ger>
Yeah, but that was years ago, and they made him cut out half the spec, no?

[02:36:42.0000] <smaug____>
MikeSmith: does having a WG use more W3C's resources than a CG?

[02:37:22.0000] <jgraham>
smaug____: Seems like it must since they get f2f meetings including TPAC and so on

[02:37:33.0000] <jgraham>
and a contact?

[02:37:40.0000] <Ms2ger>
The proposed charters are requesting 85% fte altogether

[02:38:39.0000] <jgraham>
I guess if you're going to argue it like that though; it's possible that there are people that only join W3C to participate in XForms (I don't know if that's true)

[02:40:14.0000] <jgraham>
So I am going to suggest the problem is one of focus; the W3C should dedicate it's resources to leading the web to its full potential, and not work on things that are unrelated to that

[02:40:23.0000] <jgraham>
s/'//

[02:40:27.0000] <Ms2ger>
"The Working Group may, if needed, update XML Events 2 if needed"

[02:40:50.0000] <jgraham>
Ms2ger: Best to hedge your bets

[02:40:55.0000] <Ms2ger>
"the primary risk factor will be external attention and increased adoption leading to a longer review cycle than expected."

[02:43:22.0000] <Ms2ger>
The Working Group has current plans to:

[02:43:22.0000] <Ms2ger>
    Publish a sixth edition of XML 1.0 as an Edited Recommendation, to include the changes for the LEIRI specification, at such time as IRI-bis is final.

[02:48:13.0000] <smaug____>
hmm,  XML Events implementation was IIRC my first larger contribution to Gecko :p (I then removed it couple of years later)

[02:50:49.0000] <smaug____>
"couple" == 8

[02:51:05.0000] <MikeSmith>
smaug____: having a WG definitely consumes more of W3C resources than having a CG

[02:52:11.0000] <MikeSmith>
in theory if all of our staff were capable of moving into work in other areas, then shutting down work in non-priority WGs would free up staff to help with WGs that actually matter

[02:53:47.0000] <MikeSmith>
Ms2ger: "to include the changes for the LEIRI specification, at such time as IRI-bis is final" pretty much says it all

[02:53:58.0000] <MikeSmith>
writing their own parody there

[02:54:50.0000] <Ms2ger>
This is almost as bad as Obama implementing an article from the Onion

[02:58:17.0000] <MikeSmith>
it's not quite as bad as the "Golden Key for Governments to Unlock Any Encryption" WG charter we'll sending out for AC review soon

[03:00:28.0000] <Ms2ger>
What's next, the "solve the halting problem" CG?

[03:03:25.0000] <MikeSmith>
that's the spirit

[03:03:29.0000] <MikeSmith>
optimism

[03:10:46.0000] <jgraham>
/me notes that gold is a soft metal that's therefore entirely unsuitable for making keys

[05:35:29.0000] <gsnedders>
jgraham: https://github.com/html5lib/html5lib-python/pull/198 would be nice to land sooner rather than later, FWIW

[05:36:05.0000] <gsnedders>
jgraham: as it allows us to keep up-to-date with tests without having unexpected failures

[05:37:31.0000] <gsnedders>
except it looks increasingly like there's more needed to get it to work, bah

[05:52:38.0000] <jgraham>
gsnedders: No critic review?

[06:07:23.0000] <gsnedders>
jgraham: no, doesn't appear to have picked it up

[06:11:07.0000] <gsnedders>
(FWIW, the remaining Travis failures are bugs in pytest-expect)

[06:22:55.0000] <gsnedders>
Basically need some way to serialise a set of a mixture of bytes and unicode, across both Py2 and Py3

[06:25:10.0000] <gsnedders>
(pickle on Py2 doesn't support the more recent protocols which sanely cope)

[06:32:56.0000] <webzen>
hi

[07:28:38.0000] <webzen>
Should my imports also end up in document ready ?  http://laravel.io/bin/9v6rM


2015-07-22
[03:30:09.0000] <ondras>
JakeA: a quick fetch question: is it possible to make a cross-domain anonymous request (no credentials, response available to JS) ?

[05:23:38.0000] <ondras>
hmm

[05:23:47.0000] <ondras>
anyone else with a decent fetch knowledge?

[05:41:42.0000] <JakeA>
ondras: no, that's not allowed

[05:42:30.0000] <JakeA>
Unless the response is CORS

[05:44:14.0000] <JakeA>
fetch(url) won't use credentials, but if it's cross origin it'll fail unless it passed a CORS check

[05:44:50.0000] <ondras>
damn

[05:45:11.0000] <ondras>
that would be a nice feature (as in AnonXMLHttpRequest), something not doable with a XHR I think

[05:46:02.0000] <ondras>
JakeA: what is the reasoning for not allowing this?

[05:47:33.0000] <JakeA>
ondras: it'd mean you could use the user as a proxy for content that's supposed to be secured by their wifi login

[05:47:40.0000] <JakeA>
Intranets etc

[05:48:06.0000] <JakeA>
Ideally those would have their own login, but that often isn't the case

[05:48:57.0000] <ondras>
aha, interesting, thanks

[05:49:01.0000] <JakeA>
Eg "if IP address looks like Apple employee, scan for test servers and see what they're working on"

[05:49:14.0000] <ondras>
makes full sense.

[05:49:32.0000] <ondras>
unfortunately, due to absence of progress + abort + timeout, looks like I will have to use XHR for my next project :/

[05:49:43.0000] <ondras>
good luck on moving forward with these!

[05:50:05.0000] <JakeA>
Of course, native apps have this ability to scan, but hey

[05:50:25.0000] <JakeA>
ondras: cheers. What's your abort use-case btw?

[05:51:00.0000] <JakeA>
As in, what kind if resources are you likely to abort, and under what conditions?

[05:51:31.0000] <ondras>
JakeA: in a map app, every time the use pans the viewport, I have to request data from server to display on the map

[05:51:51.0000] <ondras>
JakeA: this is a potentially lengthy operation and the user can pan/zoom the map frequently

[05:52:06.0000] <ondras>
I would like to abort the non-completed "lookup" request as soon as a new needs to be generated

[05:52:22.0000] <tilal6991>
Ms2ger: Hey. I'm working on the implementing the permissions API in blink/chromium along with mounir.

[05:52:51.0000] <tilal6991>
i.e. the one at https://w3c.github.io/permissions/

[05:53:59.0000] <tilal6991>
annevk mentioned on our intent to implement that what we have for request may not be valid idl because we cannot distinguish between a dictionary and a sequence of dictionaries

[05:54:26.0000] <tilal6991>
However, having read the webidl spec, it seems like distinguishing between the two is actually possible

[05:54:37.0000] <tilal6991>
Can you let me know if this is the case?

[05:56:27.0000] <JakeA>
ondras: gotcha. Would you say the a abort would more likely occur before receiving any of the response body, or during the response?

[05:56:54.0000] <ondras>
JakeA: before

[05:58:22.0000] <JakeA>
ondras: cheers

[05:59:02.0000] <ondras>
JakeA: good luck with fetch. and thanks for the explanation! :)

[06:11:40.0000] <ondras>
Domenic: ?

[06:34:03.0000] <Ms2ger>
tilal6991, seems like you might be correct

[06:39:37.0000] <tilal6991>
Ms2ger: awesome thnaks :)

[09:31:17.0000] <TabAtkins>
tilal6991: Yeah, it *originally* wasn't possible to distinguish, but this was brought up as an issue a while ago, and we decided to make them distinguishable.  All it means is that if your dictionary has a .length property as well, it might get mistaken as a sequence accidentally. ^_^

[09:32:18.0000] <Ms2ger>
TabAtkins, sequence uses @@iterator

[09:32:40.0000] <TabAtkins>
Ms2ger: Ah, kk. That's safer, then.

[10:18:06.0000] <wanderview>
annevk: Domenic: https://etherpad.mozilla.org/streams-f2f-july

[10:27:59.0000] <yhirano_>
wanderview: What does "distributed streams" mean?

[10:28:16.0000] <yhirano_>
wanderview: sorry, i misread.

[10:28:55.0000] <wanderview>
yhirano_: disturbed streams means reading the first part of the stream, unlocking, and then passing it on...

[10:29:26.0000] <yhirano_>
wanderview: thanks, then it is part of bodyUsed problem?

[10:29:30.0000] <wanderview>
so... the idea that partial stream reads should block further use of the Response object

[10:29:37.0000] <wanderview>
yhirano_: yea, a lot of these are related

[10:33:29.0000] <yhirano_>
wanderview: I have a question, can I write to the pad? or is it better to ask here?

[10:37:09.0000] <annevk>
yhirano_: either way is fine

[10:37:18.0000] <annevk>
yhirano_: I guess you're not in SF?

[10:37:28.0000] <yhirano_>
I'm in japan

[10:37:41.0000] <annevk>
:/ but thanks for paying attention!

[10:39:02.0000] <yhirano_>
IsDisturbed can be called for locked stream? I think it would be good to disallow monitoring locked stream.

[10:39:40.0000] <Domenic>
good point...

[10:39:48.0000] <Domenic>
it's not author-accessible though

[10:40:57.0000] <Domenic>
hmm

[10:41:06.0000] <Domenic>
yhirano_: thanks for bringing that up

[10:41:14.0000] <yhirano_>
respondWith(resp.body); console.log(resp.body.bodyUsed)

[10:45:11.0000] <yhirano_>
I think "at least one byte was read by already released readers" makes sense.

[10:47:26.0000] <Domenic>
it might be easier to just do ".read() was ever called" even if that gives unintuitive results for empty streams

[10:47:36.0000] <Domenic>
otherwise it's hard to avoid bodyUsed true -> false transitions

[10:50:17.0000] <yhirano_>
sorry I don't think my proposal causes true -> false transition.

[10:51:18.0000] <Domenic>
yhirano_: yes, but I think we want resp.body.json(); resp.bodyUsed === true

[10:53:13.0000] <Domenic>
yhirano_: otherwise consumers would have to do if (!resp.bodyUsed && !resp.body.locked) { /* can use */ }

[10:53:27.0000] <yhirano_>
hmm. I thought anyway the author should see .locked

[10:54:46.0000] <annevk>
yhirano_: what we're coming around to is that you have explicit empty (null) and maybe empty (a stream where you don't know it's really empty until you start reading it)

[10:55:12.0000] <annevk>
yhirano_: and that for the latter it's fine that IsDisturbed gets set when you start reading it, even though nothing might end up being read

[10:56:44.0000] <yhirano_>
thanks for the explanation.

[10:57:51.0000] <annevk>
yhirano_: does it seem acceptable?

[10:58:05.0000] <yhirano_>
yes.

[10:58:11.0000] <Domenic>
yay :)

[10:58:15.0000] <annevk>
\o/

[11:00:45.0000] <yhirano_>
read() on maybe empty stream sets IsDisturbed looks not so different from getReader() on maybe empty stream sets IsDisturbed, though

[11:01:11.0000] <Domenic>
that's true

[11:02:04.0000] <Domenic>
except that you might use getReader() to observe the stream without disturbing it

[11:02:18.0000] <yhirano_>
yes...

[11:02:26.0000] <Domenic>
E.g. with .closed (although that would be messy code) or some potential future .state or .queueSize or similar

[11:02:53.0000] <Domenic>
so it is probably better to stick with .read()/.cancel() as the disturbers

[11:03:33.0000] <wanderview>
yea... mutators should disturb... and allow getters without disturbing

[11:04:04.0000] <yhirano_>
ok, I have no shiny idea then.

[11:29:14.0000] <yhirano_>
wanderview, annevk, Domenic: thank you, I have to go to bed...

[11:29:26.0000] <annevk>
nn

[11:30:42.0000] <annevk>
tilal6991: hmm, it just works? Interesting, I thought dictionary or ... wasn't a thing

[11:30:56.0000] <annevk>
tilal6991: still not convinced this is the API we want to implement though

[11:34:44.0000] <TabAtkins>
annevk: It *originally* wasn't a thing, but that ended up being really annoying, so instead we do type-checking on the object first and only match it to dictionary if it fails.

[11:52:23.0000] <annevk>
I see

[13:37:15.0000] <Domenic>
annevk: https://github.com/whatwg/streams/issues/378

[13:59:03.0000] <Domenic>
https://github.com/whatwg/streams/milestones/Fetch%20with%20streams%20integration%20prerequisites

[15:46:15.0000] <annevk>
https://w3c.github.io/mediacapture-main/getusermedia.html

[15:46:41.0000] <annevk>
https://w3c.github.io/media-source/

[15:51:23.0000] <Sebmaster>
annevk: !

[15:51:32.0000] <Sebmaster>
I had a thing

[15:51:43.0000] <Sebmaster>
Lemme check what it was

[15:54:02.0000] <Sebmaster>
annevk: https://github.com/jsdom/whatwg-url/compare/ee5da1da68e016a4bcf6addd1d29f4a98191323c...590d1fa4fd9e4270c3fd8f8cdb08d7f94a65eb31 basically

[15:57:19.0000] <annevk>
file a bug against web-platform-tests?

[15:57:29.0000] <annevk>
if you mean you have new test

[16:00:49.0000] <Sebmaster>
annevk: yeah that too, but I noticed it because the spec doesn't handle 0s well

[16:00:56.0000] <Domenic>
annevk: wanderview https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL

[16:01:00.0000] <annevk>
Sebmaster: hmm, file a bug on the spec

[16:01:12.0000] <annevk>
Sebmaster: ideally with a pointer to that diff

[16:01:20.0000] <Sebmaster>
Will do... Tomorrow

[16:01:26.0000] <annevk>
Sebmaster: don't really have time today either

[16:01:32.0000] <annevk>
Sebmaster: ta!

[16:04:17.0000] <annevk>
wanderview: Domenic: https://github.com/whatwg/fetch/issues/49

[16:19:45.0000] <annevk>
jsbell: hey

[16:19:59.0000] <annevk>
jsbell: are you in the SF office by any chance and have a spare minute?

[16:20:14.0000] <jsbell>
annevk: yep...

[16:20:24.0000] <annevk>
jsbell: we're wondering about structured cloning of streams

[16:20:37.0000] <annevk>
jsbell: we can sort of figure it out, but the somewhat harder case is indexed db

[16:20:52.0000] <jsbell>
annevk: where are you?

[16:21:01.0000] <annevk>
jsbell: we're at the Moz office

[16:21:14.0000] <annevk>
jsbell: actually, Domenic thinks he wants to think it through first

[16:21:24.0000] <annevk>
jsbell: so let's leave it for today

[16:21:29.0000] <jsbell>
annevk: okie dokie


2015-07-23
[21:16:33.0000] <matttiko2>
Hi there I have a question regarding serviceWorker

[21:17:31.0000] <matttiko2>
So I try navigator.serviceWorker.register('%2f') in Chrome and it gives this error message: "Uncaught (in promise) DOMException: Failed to register a ServiceWorker: The provided scope or scriptURL includes a disallowed escape character."

[21:17:44.0000] <matttiko2>
Is it part of the spec?

[21:34:42.0000] <MikeSmith>
matttiko2: not as far as I can see

[21:35:12.0000] <MikeSmith>
the single argument there to that register call is just a URL, right?

[21:35:20.0000] <MikeSmith>
and can be relative

[21:36:45.0000] <MikeSmith>
/me looks at the latest SW editor's draft

[21:37:24.0000] <matttiko2>
MikeSmith: Yeah I tried absolute and relative URLs and both gave the same exception as long as it contains %2f or %5c

[21:39:53.0000] <MikeSmith>
matttiko2: yeah that seems like a bug in Chrome then

[21:40:19.0000] <matttiko2>
MikeSmith: Ah thanks!

[21:40:22.0000] <MikeSmith>
but you probably want to ask JakeA about that that once he's around

[21:40:29.0000] <matttiko2>
sure

[21:41:11.0000] <MikeSmith>
matttiko2: incidentally (unrelated to the handling of %2f), that URL arg is supposed to be an absolute URL, right?

[21:41:30.0000] <MikeSmith>
that's what https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#register-algorithm says at least

[21:41:51.0000] <MikeSmith>
which makes sense I suppose

[21:42:03.0000] <JakeA>
MikeSmith: matttiko2: we agreed at a f2f yesterday that %2f should reject if it's in the path name

[21:42:17.0000] <MikeSmith>
JakeA: ah ok

[21:42:44.0000] <MikeSmith>
JakeA: but is there are requirement in the spec that states the constraint for taht?

[21:42:58.0000] <JakeA>
This comes from the concessions we made over sites that treat "directories" as security boundaries

[21:43:22.0000] <MikeSmith>
ah

[21:43:27.0000] <JakeA>
And that it turns out that %2f is treated as / in a lot of servers

[21:43:37.0000] <JakeA>
It will become part of the spec

[21:43:55.0000] <MikeSmith>
k

[21:44:01.0000] <JakeA>
Chrome made the change for security reasons, and unfortunately it makes sense

[21:44:26.0000] <matttiko2>
Make sense

[21:45:14.0000] <JakeA>
matttiko2: MikeSmith: see https://github.com/slightlyoff/ServiceWorker/issues/630

[21:46:58.0000] <JakeA>
I guess it makes sense, but I'd rather we'd be able to say to these sites "you've made incorrect assumptions about how the platform works, so sorry", but it makes sense to bend over backwards a bit for these sites

[21:49:21.0000] <matttiko2>
Thanks, good to know the changes

[21:53:51.0000] <MikeSmith>
/me peruses https://github.com/slightlyoff/ServiceWorker/issues/630

[22:06:41.0000] <MikeSmith>
heh, "Thanks broken servers"

[22:06:52.0000] <MikeSmith>
we could say that about a lot of stuff

[22:06:54.0000] <MikeSmith>
sadly

[22:11:01.0000] <hgl>
will html template eventually have a declarative api? I'm very fond of react's way of creating dom elements, wish could do something similar natively. the polymer project already offers a declarative sugar like https://github.com/Polymer/TemplateBinding, is there any interest in going that direction?

[22:20:31.0000] <MikeSmith>
botie, inform annevk, given https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0155.html ("We'd like to encourage them to move to SSL for the player page... however many are unlikely to do if it means moving the video CDN to HTTPS"), I'm wondering what you think of the proposal from Ryan Sleevi at https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0371.html (which I don't think you

[22:20:32.0000] <botie>
will do

[22:20:37.0000] <MikeSmith>
ever weighed in on yet). Also wondering what hsivonen thinks of it.

[23:14:37.0000] <ondras>
Domenic: ?

[00:55:02.0000] <boogyman>
Bikeshed generation error: https://drafts.csswg.org/css-device-adapt/#viewport-meta

[07:13:21.0000] <JakeA>
matttiko2: I take it you encountered the %2f issue? Were you doing something legitimate or trying to break it?

[09:37:25.0000] <annevk>
What do you call a collection of request contexts if you want to avoid "group" and "type"?

[09:38:53.0000] <annevk>
request.context == "hyperlink" && request.contextSet == "navigation"?

[09:45:48.0000] <miketaylr>
set sounds good

[09:46:21.0000] <jsbell>
This is for a higher level grouping of context values?

[09:46:52.0000] <jsbell>
"category" comes to mind

[09:48:14.0000] <jsbell>
(or "flavour" - with the U of course - if you want to curse future generations of tech writers and non-English speakers)

[10:41:31.0000] <annevk>
jsbell: yeah

[10:41:47.0000] <annevk>
If contextSet sounds good I guess I'll go with that since it's short

[10:41:59.0000] <annevk>
And cannot be confused with context frame type or fetch group

[11:35:10.0000] <wanderview>
annevk: was your comment here about the navigator.connect() thing (which may not be as relevent now)? https://github.com/slightlyoff/ServiceWorker/issues/669#issuecomment-120247820

[11:35:33.0000] <annevk>
yeah

[11:36:28.0000] <wanderview>
ok, I will reply in the issue we don't have any problems with the current spec

[11:38:47.0000] <Domenic>
I kind of would expect contextSet to be a set, not a string

[11:38:54.0000] <Domenic>
but i have no better ideas

[11:42:30.0000] <wanderview>
annevk: I guess we couldn't use "environment" either?

[11:42:56.0000] <annevk>
Domenic: yeah...

[11:43:09.0000] <miketaylr>
what's a collection of strings... a spindle?

[11:43:18.0000] <miketaylr>
loom

[11:43:42.0000] <wanderview>
context / subcontext

[12:03:23.0000] <annevk>
wanderview: that works if we didn't have context already

[12:03:50.0000] <wanderview>
annevk: I posted in the issue... I think I would have preferred boolean getters like if(req.navigation)

[12:05:00.0000] <annevk>
req.navigation and then maybe later req.worker and/or req.resource?

[12:05:04.0000] <annevk>
maybe that's okay

[12:05:14.0000] <annevk>
I guess it was really navigation that was the annoying one, right?

[12:06:22.0000] <annevk>
wanderview: would isNavigation be too bad?

[12:06:47.0000] <wanderview>
annevk: works for me... I don't know what the web platform naming police would say

[12:07:20.0000] <annevk>
wanderview: so yeah, context being an object... it seems overkill though somewhat neater

[12:08:50.0000] <wanderview>
annevk: I don't think object is really practical without changes to webidl to let us define unique objects that can be ==='d

[12:09:13.0000] <wanderview>
.isNavigation works for me

[12:11:47.0000] <jsbell>
wanderview: can you review https://critic.hoppipolla.co.uk/r/5620 (not urgent)

[12:12:56.0000] <wanderview>
jsbell: sure... may not happen till tomorrow

[12:13:06.0000] <jsbell>
wanderview: np, thx!

[12:13:09.0000] <wanderview>
apparently my body disagrees with red eye flights

[13:20:09.0000] <annevk>
I hope they have some decent new movies on the flight tonight

[13:20:33.0000] <annevk>
That's mostly been my first world problem with flying lately... the movie selection

[13:21:04.0000] <annevk>
I guess I have varying amounts of jet lag too... Pretty bad after Whistler

[13:23:49.0000] <wanderview>
I try to download movies to my ipad... not rely on the plane entertainment

[13:24:09.0000] <wanderview>
for long international flights, though, you kind of have to

[13:24:27.0000] <wanderview>
it seemed a lot of people were watching the new Avengers on my flight

[13:29:30.0000] <Ms2ger>
Back in my day, they had just the one movie, and you could barely see it

[13:44:50.0000] <wanderview>
jsbell: is there a reason not to compare bodies in that critic PR?

[13:45:03.0000] <wanderview>
other than the helpers would have to do a lot of cloning I guess

[13:45:33.0000] <jsbell>
wanderview: right, wouldn't be synchronous, and I didn't want to restructure the tests

[13:45:41.0000] <wanderview>
oh... that too

[13:45:42.0000] <wanderview>
ok

[13:46:14.0000] <wanderview>
jsbell: we don't implement [iterable] on Headers yet, but I think it should just be a noop in those helper functions

[13:47:01.0000] <wanderview>
anyway, I'll finish looking at it tomorrow... I don't trust myself in my current condition

[13:47:06.0000] <jsbell>
wanderview: the previous version didn't compare headers entries, so that's one bit of extra fanciness I added.

[13:47:08.0000] <jsbell>
wanderview: thanks!

[14:05:03.0000] <annevk>
Ms2ger: you mean back when you were born?

[14:41:24.0000] <annevk>
mkwst: you around? https://github.com/whatwg/fetch/issues/73

[15:05:53.0000] <annevk>
Almost no change to Fetch is ever trivial

[15:26:41.0000] <annevk>
So... A document invokes fetch() and passes a body. A service worker gets that request and passes it to fetch(). Can both the document and the service worker observe the stream being read from for the purpose of progress events?

[15:26:53.0000] <annevk>
Domenic: ^

[15:27:58.0000] <annevk>
If document -> service worker involves a transfer of the stream, document will never observe it being read from as far as I can tell...

[15:36:05.0000] <annevk>
I added a comment to https://github.com/whatwg/fetch/issues/87 if someone wants to have a go at answering that question

[15:44:39.0000] <annevk>
o_O focusing happens before clicking

[15:44:51.0000] <annevk>
<p>test<input onblur=w(1) onfocus=w(this.parentNode)  onclick=this.parentNode.remove()></p>

[15:45:15.0000] <annevk>
But blur never triggers in Gecko

[16:42:07.0000] <ek_>
hi

[16:42:18.0000] <ek_>
anyone there


2015-07-24
[18:50:30.0000] <annevk>
http://discourse.wicg.io/t/standardizing-selection-behavior/971 "I'm thinking the sanest way to handle some of the most significant disagreements on selection behavior (how should whitespace be translated, should text transformations be applied) would be to add CSS rules controlling it (and then specify what the default values for those rules should be)"

[18:51:27.0000] <annevk>
Hmm did the discourse thing move again?

[18:51:31.0000] <annevk>
Why is there no HTTPS?

[18:51:54.0000] <annevk>
And why are people suggesting new features as a way of solving interop. If there's one way to get less interop, it's more features surely...

[19:05:36.0000] <MikeSmith>
annevk: I think yoav is working on getting TLS set up for that discourse site

[19:05:48.0000] <annevk>
Didn't we have it already?

[19:06:01.0000] <MikeSmith>
dunno

[19:06:24.0000] <MikeSmith>
Marcos might know more

[19:07:08.0000] <MikeSmith>
https://gitter.im/WICG/admin a place where some discussion of it has happened

[19:08:03.0000] <MikeSmith>
as far as that "I'm thinking the sanest way to handle..." I think he's well-intentioned but not representative

[19:08:30.0000] <MikeSmith>
he seems to have only gotten involved in spec discussions fairly recently

[19:09:23.0000] <MikeSmith>
and many people new who show up, their tendency often seems to be "Hey let's just add a new feature to fix that"

[19:09:41.0000] <MikeSmith>
or new element or attribute or whatever

[19:10:03.0000] <MikeSmith>
in other news https://github.com/WebAssembly/design/issues/282#issue-96942196

[19:10:18.0000] <MikeSmith>
"The comments on diffs get really hard to follow since they go away when the PR changes"

[19:10:33.0000] <MikeSmith>
I hadn't realized that, or hadn't thought about it at least

[19:10:39.0000] <MikeSmith>
that's not a good thing

[19:10:50.0000] <MikeSmith>
comments should persist somewhere

[19:11:16.0000] <MikeSmith>
or maybe they do but there's just no UI that will take you back to them in the way you'd expect

[19:11:42.0000] <annevk>
Hopefully WICG will direct people to the WHATWG FAQ

[19:11:58.0000] <MikeSmith>
annevk: yeah

[19:12:00.0000] <annevk>
Can you even contribute to the discourse if you haven't signed the CLA?

[19:12:06.0000] <MikeSmith>
yes

[19:12:11.0000] <MikeSmith>
it's open to anybody afaik

[19:12:16.0000] <annevk>
So what's the point of doing this again over the WHATWG?

[19:12:45.0000] <annevk>
If ideas can come from anywhere, the protection is bullshit

[19:12:47.0000] <MikeSmith>
doing what? the CG or the discourse thing? or all of it?

[19:12:58.0000] <annevk>
All of it, of course

[19:13:01.0000] <annevk>
:-)

[19:13:50.0000] <MikeSmith>
well I think you know some of my thoughts on that

[19:14:31.0000] <MikeSmith>
I think we had a window of opportunity where we could have gotten people to move over more to the WHATWG

[19:14:51.0000] <MikeSmith>
but some people seemed to lack the will to do that

[19:15:01.0000] <annevk>
I talked with someone from Microsoft and the impression I got was that this setup was supposed to be more "secure", but it sounds like it's just yet another venue

[19:15:01.0000] <MikeSmith>
or the stomach for it

[19:15:39.0000] <MikeSmith>
on the other hand I don't want to fault anybody for trying new ways of doing things

[19:15:45.0000] <annevk>
Didn't realize that. If they want to come they're welcome

[19:16:03.0000] <MikeSmith>
I think it's not an either-or anyway

[19:16:10.0000] <annevk>
Sure thing, I don't mind

[19:16:58.0000] <MikeSmith>
I wish people would quit thinking of their sets of collaborators they way they think of their hometown football club

[19:17:19.0000] <MikeSmith>
or like some kind of flag-waving nationalistic thing of something

[19:17:19.0000] <annevk>
Haha

[19:17:45.0000] <boogyman>
and of course you mean American Football ;). haha

[19:18:20.0000] <MikeSmith>
on the other hand, it's a waste of time if we have to rebuild stuff that's working just fine

[19:18:42.0000] <annevk>
Yeah, I guess I'm mostly trying to figure out what the point here is

[19:18:49.0000] <MikeSmith>
I mean, rebuild it somewhere else just for the sake of somebody wanting to have some different place they can claim as their own

[19:18:55.0000] <annevk>
I guess to some extent it's about diluting the value of WGs even more

[19:19:01.0000] <MikeSmith>
bingo

[19:19:04.0000] <MikeSmith>
and that's a good thing

[19:19:10.0000] <MikeSmith>
well I shouldn't say that

[19:19:20.0000] <MikeSmith>
I don't mean in it absolutely

[19:19:32.0000] <MikeSmith>
it's just that WGs cost us all a lot more

[19:19:36.0000] <MikeSmith>
as we well know

[19:19:55.0000] <MikeSmith>
process/political overhead, etc.

[19:20:11.0000] <annevk>
Gotta board. Talk to you later MikeSmith!

[19:20:18.0000] <MikeSmith>
cheers man

[19:20:36.0000] <annevk>
Thank you!

[20:25:43.0000] <MikeSmith>
botie, inform annevk FYI about "e.g." and commans, look through the Economist Style Guide at https://www.w3.org/2001/06/manual/ and do find-in-page for "eg,". Economist apparently uses "eg" with no periods. Which I kind of like personally but I think is a fairly idiosyncratic, odd style that's not widely used elsewhere. But regardless, they always put a comma after it. For one thing, without the periods,

[20:25:43.0000] <botie>
will do

[20:25:49.0000] <MikeSmith>
 it would look pretty odd if not followed by a comma.

[20:25:59.0000] <MikeSmith>
oofs

[20:27:13.0000] <MikeSmith>
botie, inform annevk oofs, the Economist Style Guide page I meant to point you to is http://www.economist.com/styleguide/a

[20:27:13.0000] <botie>
will do

[22:14:54.0000] <zewt>
firefox: congrats at making me turn off errors in the console by spamming pages of pointless https sha-1 warnings

[22:15:04.0000] <zewt>
mission accomplished

[22:20:33.0000] <MikeSmith>
https://twitter.com/awfulben/status/624342316271149057 is kind of a downer. "I find it quite funny the W3C CSS Working Group is concerned about its image. As if it could get any worse... :)"

[22:20:44.0000] <MikeSmith>
dunno where that's coming from

[22:20:59.0000] <MikeSmith>
doesn't even qualify as snarky

[22:22:07.0000] <MikeSmith>
I wish if people are going to make the effort to bash others they at least try to work some minimal amount of humor into it

[06:59:59.0000] <wanderview>
Domenic: I guess safari might be the first implementation of the ReadableStream constructor?  http://blogs.igalia.com/xrcalvar/2015/07/23/readablestream-almost-ready/

[07:00:17.0000] <wanderview>
Domenic: if there are thoughts to move to the strategy pattern with the controller... does that cause problems for them?

[07:01:04.0000] <Domenic>
wanderview: I do not think so, it would be done in an unobtrusive way. E.g. if you implemented pullInto in addition to pull, now you are RBS. Or if necessary there's an explicit flag.

[07:01:19.0000] <wanderview>
ok

[08:02:54.0000] <ek_>
hi

[08:02:54.0000] <botie>
privet, ek_

[08:04:14.0000] <ek_>
anyone there

[08:10:39.0000] <botie>
annevk, at 2015-07-24 03:25 UTC, MikeSmith said: FYI about "e.g." and commans, look through the Economist Style Guide at https://www.w3.org/2001/06/manual/ and do find-in-page for "eg,". Economist apparently uses "eg" with no periods. Which I kind of like personally but I think is a fairly idiosyncratic,

[08:10:40.0000] <botie>
odd style that's not widely used elsewhere. But regardless, they always put a comma after it. For one thing, without the periods, and at 2015-07-24 03:27 UTC, MikeSmith said: oofs, the Economist Style Guide page I meant to point you to is http://www.economist.com/styleguide/a

[08:14:43.0000] <ek_>
yoav are you there?

[08:15:00.0000] <yoav>
ek_: Yup

[08:15:09.0000] <ek_>
Hey how is it going

[08:15:16.0000] <ek_>
I need to ask you a question

[08:15:42.0000] <yoav>
ek_: Sure

[08:15:52.0000] <ek_>
The load event on an object is fired when it has been loaded. As per HTML5 specs events comes from specific task source(http://www.w3.org/TR/html5/single-page.html#generic-task-sources). I was wondering what is the task source of the load event?

[08:16:26.0000] <yoav>
not sure. tbh

[08:17:05.0000] <yoav>
zcorpan would be a good person to ask that, but he's not around for the next few weeks

[08:17:48.0000] <ek_>
ok

[08:25:33.0000] <Ms2ger>
ek_, you don't want to look at that ancient fork

[08:25:47.0000] <Ms2ger>
https://html.spec.whatwg.org/multipage/

[08:28:13.0000] <ek_>
Ms2ger, This one also mentions Task sources but dont mention the task source for the load event

[08:29:17.0000] <Ms2ger>
Which load event is this? The one on the document?

[08:30:49.0000] <ek_>
i am talking about the onload event which could be fired on any object

[08:31:19.0000] <Ms2ger>
In that case, "it depends"

[08:31:29.0000] <annevk>
"Not in particular, just all of them, and their visual style and overall IA, accessibility, pretty much 1995."

[08:31:38.0000] <annevk>
oh Twitter, you're so useful

[08:31:59.0000] <ek_>
it depends on what?

[08:32:10.0000] <annevk>
ek_: not all load events are equal

[08:32:45.0000] <annevk>
ek_: I would expect most to be dispatched from the networking task source, but e.g. I'm pretty sure window.onload is different

[08:33:32.0000] <Ms2ger>
Yeah, that's DOM manip

[08:34:40.0000] <ek_>
so in case of window.onload which task source would be used

[08:34:50.0000] <ek_>
oh okay

[08:39:39.0000] <Ms2ger>
ek_, fwiw, that's defined at the end of the section at https://html.spec.whatwg.org/multipage/syntax.html#the-end

[08:39:58.0000] <gsnedders>
.

[08:40:06.0000] <annevk>
https://twitter.com/marxo/status/624604621579784194 lol

[08:40:18.0000] <annevk>
I guess I should stop trying to reason with this person

[08:43:12.0000] <wanderview>
annevk: I imagine its hard to understand why specs are written the way they are if you never have to try to implement them in a browser

[08:44:08.0000] <tantek>
wanderview: even if you do have to implement them, you still have to jump around a lot (in one spec, across specs) because of dependencies

[08:44:25.0000] <tantek>
(HTML in particular)

[08:44:49.0000] <wanderview>
tantek: thats true... and sometimes there are multiple copies of specs and its unclear which is the "correct" one

[08:45:02.0000] <wanderview>
or abandoned specs that are still published

[08:45:11.0000] <tantek>
annevk - your replies were a good attempt. But you're right, there's not much more to say after that response.

[08:45:44.0000] <tantek>
wanderview: or published specs that are abandoned too (like most of /TR and most RFCs) :/

[08:45:55.0000] <annevk>
I'm kind of interested to know what he means by forking

[08:46:04.0000] <annevk>
If he can't understand it, seems hard to fork...

[08:46:31.0000] <tantek>
agreed. OTOH if he does actually fork a spec and rewrite it to make it more readable/understandable - that would be interesting to take a look at.

[08:46:38.0000] <tantek>
good thing we have licenses that encourage that :)

[08:47:00.0000] <annevk>
I guess I can ask about his more readable fork

[08:47:21.0000] <tantek>
also this is a good use-case for forking - no actual (intended at least) feature/functionality/interop changes, just readability/usability

[08:47:56.0000] <tantek>
annevk: note also that their background has {less} and Sass on it - that's probably an indicator as the perspective they're coming from.

[08:48:31.0000] <annevk>
Yeah, although hints as to how to improve would be welcome. "You're stuck in 1995" doesn't quite resonate. I wasn't even ten back then.

[08:49:34.0000] <tantek>
I missed that remark

[08:49:51.0000] <gsnedders>
I was talking to a friend recently who was amazed that there's no even unofficial edited version of RECs including errata

[08:50:20.0000] <tantek>
that being said, W3C spec styling/template is pretty stuck, and WHATWG spec styling/template in some respects had no choice but to copy that to "look" like a web standard from the perspective of those who are used to reading W3C specs.

[08:50:30.0000] <annevk>
tantek: https://twitter.com/marxo/status/624592600377327618

[08:51:22.0000] <annevk>
There's only so many ways you can format an algorithm though :-)

[08:51:34.0000] <tantek>
gsnedders: believe it or not I push for that quite often as something the AB should say is "ok" for WG to do, and haven't gotten very far. Still pushing though.

[08:51:40.0000] <tantek>
s/WG/WGs

[08:51:57.0000] <gsnedders>
annevk: IA?

[08:51:59.0000] <tantek>
annevk - he's not talking about the algorithm stuff

[08:52:04.0000] <Ms2ger>
Internal affairs?

[08:52:05.0000] <annevk>
gsnedders: I suspect information architecture

[08:52:10.0000] <Ms2ger>
But then people would be inclined to look at EDs!

[08:52:21.0000] <tantek>
he's talking about like I said, the style sheet, all the header, all the preamble crap etc.

[08:52:33.0000] <tantek>
yes IA = information architecture here

[08:52:49.0000] <tantek>
the styling of specs derives from lots of legacy IA

[08:52:51.0000] <annevk>
https://twitter.com/marxo/status/624608066667843584 hmm

[08:53:02.0000] <annevk>
Maybe English is not his first language

[08:53:04.0000] <tantek>
that predates even W3C, IETF - a lot of is like academic papers

[08:53:05.0000] <gsnedders>
I thought fantasai was about to try and get the W3C to adopt a stylesheet based on the CSS WG EDs?

[08:53:10.0000] <Ms2ger>
I hear bikeshed is moving some of the preamble stuff to the back of the bus, though

[08:53:22.0000] <tantek>
gsnedders - not just stylesheet but spec restructuring too

[08:53:41.0000] <gsnedders>
And she sounded pretty upbeat about her chanes, which seems good, given how far previous attempts have got

[08:54:00.0000] <tantek>
I was working on that with fantasai and sylvain - but I wanted to make much more drastic changes than they wanted to so we didn't make much progress.

[08:54:14.0000] <tantek>
Ms2ger - that's good to hear

[08:54:34.0000] <tantek>
instead I gave up on that and instead starting formating microformats specs with a better intro / section order

[08:54:49.0000] <tantek>
minimizing all the longwinded / and overly styled header/preamble/intro/abstract crap

[08:54:53.0000] <gsnedders>
tantek: oh, I'd forgotten you were involved. :) I'd remembered there were others involved, but couldn't remember who else was included in the "we" she spoke of :)

[08:55:04.0000] <tantek>
gsnedders: yes, it was three of us

[08:55:15.0000] <Ms2ger>
It's annoying when you need something at the end, though, because now there's so much crap there :)

[08:55:34.0000] <gsnedders>
Ms2ger: what, like the HTML ack section? ;P

[08:55:55.0000] <Ms2ger>
At least that's nice crap, it has my name :)

[08:56:42.0000] <tantek>
annevk I have to agree with these criticisms though: https://twitter.com/marxo/status/624592600377327618

[08:56:52.0000] <tantek>
the problem is that it's hard to suggest specific small incremental changes to fix that

[08:57:02.0000] <tantek>
that is - too difficult to do with just a series of pull requests

[08:57:11.0000] <tantek>
to fix those problems a spec really needs a rewrite and re-ordering

[08:58:23.0000] <tantek>
here's a concrete example of a different way to order and explain sections in a spec: http://microformats.org/wiki/h-card

[08:58:46.0000] <gsnedders>
the intro for HTML is ridiculously long

[08:58:54.0000] <tantek>
yes

[08:59:50.0000] <gsnedders>
but then people argue bullshit that the conformance critetia section settles, and then all the notation stuff which I'm always unsure if it's wrothwhile having…

[09:00:26.0000] <gsnedders>
basically it annoys me so much stuff is needed to avoid debates

[09:00:53.0000] <Ms2ger>
We need a spec for specs

[09:01:19.0000] <gsnedders>
Maybe. Like a new RFC 2119, really. Because that gets rid of a lot of common boilerplate.

[09:03:15.0000] <annevk>
tantek: well, you could lead by example

[09:03:33.0000] <tantek>
annevk - that's what I'm trying to do with with microformats.org specs, and IndieWebCamp.com specs

[09:03:56.0000] <tantek>
gsnedders - anything needed to "avoid non-technical debates" can go in appendices

[09:04:01.0000] <tantek>
it's all esoterica

[09:04:05.0000] <annevk>
those are not really known for their implementability :-)

[09:04:06.0000] <tantek>
that's the point

[09:04:41.0000] <tantek>
annevk - ironically, they're more implementable, by much smaller teams (e.g. 1 person implementable)

[09:05:03.0000] <tantek>
that's part of the point of the work in both of those groups - much simpler specs / standards that individuals can implement all by themselves on their own websites

[09:05:27.0000] <tantek>
rather that requiring large orgs with large paid staffs to do so (most W3C, IETF, and even WHATWG specs)

[09:05:58.0000] <annevk>
I think you're missing my point

[09:06:00.0000] <tantek>
to be fair - we're solving different problems

[09:06:07.0000] <tantek>
annnevk - possibly

[09:07:33.0000] <tantek>
annevk - another spec, more algorithm style if you like: http://microformats.org/wiki/microformats2-parsing

[09:07:48.0000] <tantek>
has also been implemented by multiple individuals (different implementations), in multiple languages

[09:08:13.0000] <annevk>
"follow the HTML parsing rules" hah, you haven't exactly simplified things here :-P

[09:08:26.0000] <annevk>
just imported a 100k line spec

[09:08:30.0000] <tantek>
hey - it basically says not to reinvent an HTML parsing spec!

[09:08:47.0000] <tantek>
right - use an existing HTML parsing implementation!

[09:08:58.0000] <tantek>
(or the equivalent thereof)

[09:09:09.0000] <gsnedders>
I still want to try programmatically generate an impl from the spec

[09:09:16.0000] <gsnedders>
which isn't that easy

[09:09:18.0000] <tantek>
I think your "not really known for their implementability" information is about 6 years out of date, if you're referring to e.g. hsivonen's complaints of yore.

[09:09:30.0000] <tantek>
gsnedders lol - that's a very bad path to go down - you end up with things like XML Schema

[09:09:52.0000] <gsnedders>
tantek: nah, I mean from the current HTML spec, generate an HTML parser from it

[09:09:59.0000] <gsnedders>
tantek: without alterting the spec

[09:10:02.0000] <annevk>
gsnedders: how close is JavaScript?

[09:10:15.0000] <tantek>
gsnedders - yup - that path of argument is exactly what the declarative grammar camps argue

[09:10:23.0000] <tantek>
all those grammars in RFCs etc.

[09:10:42.0000] <Domenic>
I would love if some designer were willing to do a stylesheet redesign/PR/etc.

[09:10:45.0000] <gsnedders>
annevk: you can't really, tbf, if you want a decent implementation. esp ES6 makes it harder.

[09:10:47.0000] <tantek>
it turns out the machine generatable code is wrong - because such declarative grammars only ever approximate the actual grammars

[09:11:06.0000] <gsnedders>
tantek: this is why I want to do it from the English prose :)

[09:11:09.0000] <tantek>
Domenic: it's not just style sheet - that's the problem. there needs massive content re-ordering and restructuring.

[09:11:15.0000] <gsnedders>
tantek: even though it'll be brittle

[09:11:25.0000] <tantek>
gsnedders: hah - that sounds like a Google natural language processing science project ;)

[09:11:34.0000] <tantek>
perhaps you should apply :D

[09:11:35.0000] <Domenic>
I guess I don't really agree with that (and it's unclear that's what the tweet was saying either)

[09:11:46.0000] <tantek>
not unclear at all - that's the point about IA that's being made

[09:11:48.0000] <Domenic>
It seemed like a designer saying "this is too ugly, I design pretty things all day"

[09:11:59.0000] <gsnedders>
tantek: second person in a month trying to get me to work at Google!

[09:12:15.0000] <tantek>
Domenic: that's a very superficial summary of that critique

[09:12:32.0000] <Domenic>
It was a very superficial critique, to be fair

[09:12:37.0000] <tantek>
gsnedders: don't take it as an insult

[09:12:41.0000] <gsnedders>
tantek: the sentences are relatively regular within the spec, I still suspect you can do it through pattern matching

[09:12:42.0000] <Domenic>
I think you might be projecting your own grievances into it :)

[09:12:46.0000] <tantek>
Domenic: hah. as if Twitter were capable of much more ;)

[09:12:48.0000] <gsnedders>
tantek: nah, I didn't, just amusing :)

[09:13:20.0000] <tantek>
Domenic: perhaps. though you might be ignoring the points about IA

[09:13:52.0000] <gsnedders>
tantek: like, most sentences you can change into one instruction of the spec's VM

[09:14:07.0000] <gsnedders>
tantek: it's the if/otherwise stuff that scares me

[09:16:58.0000] <Ms2ger>
Domenic, didn't someone do a redesign for w3c specs at one point that was all pretty?

[09:17:06.0000] <Domenic>
Ms2ger: I do have memories of that

[09:17:39.0000] <gsnedders>
Ms2ger: yeah

[09:28:28.0000] <tantek>
since tons of Google people hangout here - how does Google Search NOT have a "one box" for dates and months?!?

[09:29:08.0000] <tantek>
e.g. a search for November 2015 should show a one box view of the whole month of November as the first thing, with (local) holidays, not some useless link to timeanddate(.)com

[09:29:30.0000] <tantek>
seems like a super simple, minimal, obvious thing to build

[09:29:50.0000] <tantek>
or heck if you're one of those "cards" people, a "card" for a month

[09:30:05.0000] <tantek>
maybe even showing you summary info from your gcal if you happen to be logged in

[09:30:13.0000] <tantek>
there's your freebie for the day ;)

[09:30:54.0000] <tantek>
I'm sure you can do better than: http://www.wincalendar.com/November-Calendar/November-2015-Calendar.html

[09:36:45.0000] <tantek>
annevk - do you keep the markup for your blog somewhere e.g. github that can accept pull requests?

[09:37:46.0000] <annevk>
nope

[09:38:39.0000] <annevk>
I probably should at some point, but... work

[09:52:49.0000] <SimonSapin>
Does the HTML spec have a machine-readable list of element names and attribute names?

[09:53:41.0000] <tantek>
You mean like a DTD?

[09:53:44.0000] <tantek>
/me ducks.

[09:54:17.0000] <SimonSapin>
whatever. I’d like to auto-generate this file: https://github.com/servo/string-cache/blob/master/plugin/src/atom/data.rs

[09:55:19.0000] <gsnedders>
SimonSapin: what element names?

[09:55:42.0000] <gsnedders>
SimonSapin: those that are valid? those that are special cased in the parser? those that any processing is defined for?

[09:57:08.0000] <SimonSapin>
The union of all of those I suppose. Names not in that set would be interned slightly less efficiently. But https://html.spec.whatwg.org/multipage/indices.html#elements-3 can be a good start

[09:59:22.0000] <tantek>
SimonSapin, perhaps you could suggest a format for this machine-readable list of element names and attribute names?

[09:59:30.0000] <SimonSapin>
json?

[09:59:36.0000] <tantek>
ROFL

[10:00:03.0000] <SimonSapin>
like https://encoding.spec.whatwg.org/encodings.json

[10:00:53.0000] <SimonSapin>
tantek: do you have another favorite format?

[10:01:18.0000] <tantek>
SimonSapin: JSON isn't a format, it's a syntax.

[10:01:30.0000] <SimonSapin>
uh, ok

[10:01:58.0000] <SimonSapin>
so what’s a format?

[10:02:02.0000] <tantek>
e.g. in that encoding.json thing you linked to, the set of things like "encodings" "labels" "heading" and how they're arranged/nested - THAT is a format.

[10:02:36.0000] <tantek>
you could serialize that format likely in another syntax too, like XML

[10:03:11.0000] <SimonSapin>
I don’t really care. For this specific use case I only want to extract a list of strings for the element names, but maybe other people would find useful to include more data from https://html.spec.whatwg.org/multipage/indices.html in that format

[10:04:16.0000] <tantek>
wow there's a whole site for it: http://www.html5dtd.org/

[10:04:39.0000] <gsnedders>
there's also the old out of date ones what whattf.org/.net or whatever it is

[10:04:55.0000] <gsnedders>
originally by fantasai then updated by hsivonen but I think now totally abandoned

[10:05:06.0000] <gsnedders>
maybe those were RelaxNG though?

[10:05:44.0000] <tantek>
SimonSapin: if you really don't care, here's the XML Schema for XHTML5: http://blogs.msdn.com/b/webdev/archive/2009/11/18/html-5-intellisense-and-validation-schema-for-visual-studio-2008-and-visual-web-developer.aspx - specifically the zip file: http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-09-92-49-22/html5.zip

[10:05:46.0000] <tantek>
s/the XML/an XML

[10:06:38.0000] <tantek>
source: http://stackoverflow.com/questions/4053917/where-is-the-html5-document-type-definition from a web search for "HTML5 dtd"

[10:06:41.0000] <tantek>
enjoy!

[10:10:52.0000] <gsnedders>
http://syntax.whattf.org

[10:10:53.0000] <SimonSapin>
I was hoping for something maintained with the spec (so that it’s kept up to date), though I suppose these days HTML is not adding new elements much

[10:10:55.0000] <gsnedders>
is what I was thinking of

[10:12:49.0000] <gsnedders>
https://github.com/validator/validator/tree/master/schema/html5 seems to be where they are now

[10:36:19.0000] <TabAtkins>
gsnedders: I'm still vaguely interested in writing CSS Syntax in an executable English.

[10:46:18.0000] <gsnedders>
TabAtkins: how close is it now?

[10:46:26.0000] <TabAtkins>
Pretty close!

[10:46:39.0000] <TabAtkins>
I'd just need to be a little more consistent in how I phrase some things.

[10:50:48.0000] <TabAtkins>
Ugh, and I desperately need to spend a few days on perf-tuning Bikeshed again.

[11:13:36.0000] <wanderview>
JakeA: slightlyoff: anyone doing a tl;dr post of the f2f notes?

[11:45:58.0000] <JakeA>
wanderview: that's a good idea. Think a blog post is OK or should it be somewhere more official (

[11:46:54.0000] <wanderview>
JakeA: I can try my hand at a blog post... but I don't know where something "official" would go for something like this

[11:47:15.0000] <wanderview>
also, I like that I can basically say the blog post is from my point of view, etc... lower bar :-)

[11:58:36.0000] <wanderview>
hmm, or maybe I should just focus on the bit that interests me

[12:03:02.0000] <JakeA>
I'm happy with that or a more general post

[13:17:39.0000] <Domenic>
SimonSapin: file a bug, this is a thing that can happen

[13:22:55.0000] <ondras>
Domenic: ?

[13:23:28.0000] <Domenic>
ondras: stop sending me random characters

[13:24:07.0000] <ondras>
Domenic: sorry, those were pretty deterministic question marks only. A common way to check for somebody's presence. Sorry to offend you.

[13:24:43.0000] <Domenic>
ondras: not offended, just confused what they were supposed to accomplish. I'm obviously here, as I said something.

[13:24:48.0000] <ondras>
Domenic:  is there some common pattern when a class method returns a promise whose resolution depends on further method calls inside that class? So the (resolve, reject) functions need to be "stored" somewhere, preferrably not in a closure to increase readability...

[13:25:37.0000] <Domenic>
ondras: ideally use more promises so that you never end up needing `new Promise`. https://stackoverflow.com/questions/23803743/what-is-the-explicit-promise-construction-antipattern-and-how-do-i-avoid-it

[13:25:54.0000] <Domenic>
ondras: otherwise I just store them as underscored variables

[13:28:15.0000] <ondras>
I *think* I am not going to the antipattern mentioned above. I have a Request class with a promise-returning send() method. This method accepts an options object, stores it in this._options and uses it when parsing the response, just before resolving.

[13:29:46.0000] <ondras>
Domenic: http://jsfiddle.net/xd426120/

[13:29:54.0000] <ondras>
a code sample is probably more descriptive.

[13:30:05.0000] <ondras>
so this is considered okay? or are there better approaches?

[13:30:10.0000] <Domenic>
ondras: I think StackOverflow will probably give you good answers for this; there is a fairly active promise community there.

[13:30:19.0000] <ondras>
namely with this event-based promise resolution...

[13:30:44.0000] <ondras>
Domenic: I would somewhat trust your opinion more than the highest ranking SO answer out there.

[14:00:31.0000] <TabAtkins>
Domenic: Probably can remove the code { color: ... } from the WHATWG stylesheet, at least for code.highlight elements.  It makes it harder to read.

[14:01:39.0000] <TabAtkins>
ondras: http://www.nohello.com/

[14:07:22.0000] <ondras>
TabAtkins: yeah. turns out that people often idle here for quite a long time, so one has to re-phrase and re-ask the question several times in order to get a response. A "?" roughly translates to "hi, is this a good time for you to be asked a question", at least in the IRC communities I normally frequent.

[14:07:47.0000] <TabAtkins>
ondras: Not in this community. ^_^

[14:07:53.0000] <ondras>
.)

[14:09:48.0000] <wanderview>
JakeA: do you think we should lock down the meeting notes to comment-only at this point?  (afraid to link an everyone-can-edit page to a blog post)

[14:46:35.0000] <TabAtkins>
wanderview: Absolutely do not link to an everyone-can-edit document. ^_^

[15:03:18.0000] <mrtn_>
are there any plans to standardize the window.devicePixelRatio or introduce a property which does not change with the zoom level and only represents the ideal screen DPR?

[15:42:36.0000] <gsnedders>
mrtn_: it's in CSSOM View

[16:08:56.0000] <gsnedders>
TabAtkins: you want me to take a try at programmatically converitng CSS Syntax?

[16:09:12.0000] <TabAtkins>
That wasn't my intention, but I'm not opposed to you trying.

[16:11:37.0000] <gsnedders>
TabAtkins: eh, it's probably simpler than starting off with HTML!

[16:11:45.0000] <gsnedders>
tbf, I don't think the HTML /tokenizer/ will be that hard

[16:11:46.0000] <TabAtkins>
Yeah, much smaller. ^_^

[16:17:38.0000] <gsnedders>
it's not the size that matters, really, with doing it programmatically

[16:17:46.0000] <gsnedders>
it's the level of complexity of the instructions

[16:18:00.0000] <gsnedders>
also I'm drunk so you probably should take what I say with a grain of salt :)

[16:18:43.0000] <TabAtkins>
Size matters insofar as you still have to edit the text to get it into a parsable representation.

[16:18:56.0000] <TabAtkins>
And Syntax is fairly small as far as parsing specs go.

[16:18:56.0000] <gsnedders>
I was trying to avoid doing that :)

[16:42:48.0000] <TabAtkins>
gsnedders: I doubt you can totally avoid it. Syntax is *close* to a parsable English, but not quite regular enough.

[16:45:40.0000] <gsnedders>
We'll see. Maybe sober-gsnedders will think it harder. :)


2015-07-25
[04:26:24.0000] <nox>
Hello.

[04:28:59.0000] <nox>
I'm trying to make a PR for the DOM spec and bikeshed says "FATAL ERROR: No 'dfn' refs found for 'parse a relative selector'". What am I doing wrong?

[07:19:26.0000] <mrtn_>
can anyone tell me when the picture element and srcset attribute were added to the living standard for the first time?


2015-07-26
[02:26:22.0000] <annevk>
nox: maybe you need to run bikeshed update?

[02:26:27.0000] <annevk>
nox: I don't get fatal errors here

[02:26:39.0000] <annevk>
nox: I do have two warnings I need to remove at some point

[02:48:02.0000] <nox>
annevk: Still the same after bikeshed update.

[02:48:48.0000] <annevk>
Maybe I need to run bikeshed update

[02:49:12.0000] <nox>
Ah ah.

[02:49:31.0000] <nox>
annevk: Did you take a look at <https://github.com/whatwg/dom/issues/60>?

[02:51:28.0000] <annevk>
nox: it shouldn't matter

[02:51:55.0000] <annevk>
nox: it'll only matter if you implement synchronous notifications on top for internal usage

[02:52:21.0000] <annevk>
nox: e.g. to implement "iframe removed from document"

[02:52:32.0000] <nox>
annevk: That's what I gathered, but in Servo we strive to make the code look as the spec states and I do have to queue the mutation record after the mutation there (because the machinery is used for things that are not related to queuing of mutation records).

[02:53:05.0000] <nox>
So I was wary of inversing the steps.

[02:53:36.0000] <annevk>
What's the machinery used for?

[02:53:55.0000] <nox>
annevk: Updating Node.childNodes.

[02:54:02.0000] <nox>
And other things, like updating Document.title

[02:54:27.0000] <annevk>
I still don't get any errors

[02:54:32.0000] <nox>
Weird.

[02:54:48.0000] <annevk>
Updating document.title? That should be a lazy getter...

[02:55:35.0000] <nox>
annevk: How do you update the window's title

[02:56:47.0000] <annevk>
I think for that kind of stuff you'd like to just observe the title element, but I'm not entirely sure what would be the best

[02:58:03.0000] <nox>
Well, consider I'm observing it,

[02:58:37.0000] <nox>
I would have to allocate an actual mutation observer and whatnot, so instead I use the underlaying infrastructure for this,

[02:58:54.0000] <annevk>
I wonder if TabAtkins could look into your bikeshed problem... I wonder what's different between our setups

[02:59:09.0000] <nox>
but if the mutation didn't happen yet, that means I can't just get the text content of <title> and have to work with removedNodes and addedNodes.

[02:59:26.0000] <nox>
annevk: Mmmh, I don't have an error anymore, must have done something wrong.

[03:00:25.0000] <nox>
I still think this ordering inconsistency should not be there, if only just to be consistent.

[03:01:45.0000] <nox>
And it bothers me when propagating the mutation to Node.childNodes.

[03:04:20.0000] <nox>
annevk: When making a PR, should I submit changes to the HTML file too?

[03:05:00.0000] <annevk>
nox: yeah, if you can run bikeshed that'd make integration easier

[03:05:09.0000] <annevk>
nox: I guess I should mention something like that in the README

[03:05:15.0000] <nox>
Ok, it made a lot of changes, that's why I ask.

[03:06:20.0000] <nox>
annevk: Running bikeshed on master says:  1 file changed, 771 insertions(+), 773 deletions(-)

[03:07:52.0000] <annevk>
nox: seems okay

[03:14:24.0000] <nox>
annevk: Err, I think https://github.com/whatwg/dom/issues/59 is still not the right fix.

[03:14:35.0000] <nox>
annevk: previousSibling will be wrong if node == child, AFAICT.

[03:15:12.0000] <annevk>
reopened

[03:15:20.0000] <annevk>
will look at it later

[03:16:47.0000] <nox>
Ok.

[07:13:48.0000] <annevk>
wanderview: so respondWith() is kind of a racy way to get a Response to be read...

[07:14:18.0000] <annevk>
wanderview: e.g. if you pass a Response to both respondWith() and something else that takes a promise for a Response (do we have anything like that?) it's unclear which will win...

[09:43:31.0000] <annevk>
What's the point of having https://github.com/orgs/whatwg/teams/contributors ?

[09:56:06.0000] <annevk>
I enabled third-party restrictions for the WHATWG repo, let me know if I broke anything

[09:57:57.0000] <boogyman>
annevk: that url is not public (inot sure if that's helpful feedback)

[09:59:45.0000] <annevk>
boogyman: thanks, but doesn't matter

[11:03:47.0000] <Domenic>
botie: tell annevk I think contributors was designed so I could assign bikeshed-related issues to tabatkins

[11:03:47.0000] <botie>
Domenic: what?

[11:08:20.0000] <TabAtkins>
annevk: There was a problem a day or two ago where the CSSWG specs had cascading failures; that's fixed now.

[11:08:49.0000] <TabAtkins>
annevk: That temporarily wiped out most of the definitions coming from CSS specs.

[11:14:46.0000] <TabAtkins>
(Also, now I track what version the repo's data files are, so if I update those and you haven't manually updated in a while, you'll pick up the updated files for free.)

[11:47:33.0000] <wanderview>
annevk: as far as I know, there is nothing else that takes a Promise<Response> like respondWith()

[11:51:43.0000] <wanderview>
annevk: and I think I confirmed with bz recently that .respondWith() and .waitUntil() are the first standard webidl we have that takes a promise as an argument (there may be a moz-specific API as well)

[11:53:12.0000] <annevk>
yeah that seems correct

[15:43:58.0000] <TabAtkins>
Domenic: The example code in 4.2.2 of the promises guide is actually super confusing.

[15:44:37.0000] <TabAtkins>
"Run the following in parallel" suggests that the two substeps are meant to race each other in parallel, when that's exactly opposite.

[15:45:33.0000] <TabAtkins>
I thought the suggestion was to put the async section at the end, with an explicit "return foo, and continue the rest of this algorithm async"


2015-07-27
[18:08:17.0000] <MikeSmith>
Domenic, for botie, I think you currently need to use "inform" instead of "tell" (I'll try to hack my copy of its source to add support for "tell", or maybe it's already been added upstream and I just need to pull it)

[21:50:04.0000] <MikeSmith>
botie: tell Domenic botie now understands "tell"

[21:50:04.0000] <botie>
will do

[22:29:32.0000] <annevk>
TabAtkins: https://fetch.spec.whatwg.org/#dom-global-fetch uses that style

[22:29:53.0000] <annevk>
TabAtkins: https://storage.spec.whatwg.org/#dom-storagemanager-requestpersistent does too

[22:30:26.0000] <annevk>
TabAtkins: given that "in parallel" is defined I don't think it matters much

[22:41:08.0000] <annevk>
Domenic: I can't assign issues to TabAtkins so I don't think that works

[22:41:23.0000] <annevk>
Domenic: we'd have to actually give contributors access to a set of repositories for that

[22:50:55.0000] <TabAtkins>
annevk: Of course it matters! It doesn't matter if there's a link to the full meaning if the plain English reads completely wrong.

[23:00:05.0000] <annevk>
TabAtkins: yeah, I guess we disagree on the plain English reading wrong

[23:10:51.0000] <TabAtkins>
At least in my ideolect, "Do the following Xs in parallel" means that they'll all execute at the same time.  (Not that they'll run in series, in parallel with the surrounding context.)

[23:12:56.0000] <annevk>
In that case "Run the remaining Xs in parallel" would mean the same thing

[23:13:36.0000] <annevk>
So neither would be clear with such an interpretation

[23:19:33.0000] <TabAtkins>
Which is why I'm not suggesting either.  There's another phrasing, used in Font Loading, which isn't possible to misunderstand.

[23:25:05.0000] <annevk>
Well, except it doesn't define "asynchronously" and we've had a bunch of concerns raised over the word "asynchronous" which is why it's "in parallel" (and is somewhat defined) now

[23:26:53.0000] <annevk>
You also update internal slots from asynchronous thread which seems all kinds of wrong

[23:26:59.0000] <annevk>
an*

[23:47:21.0000] <annevk>
philipj: I was thinking, we could also restrict requestFullscreen() on <iframe> by doing an inclusive ancestor check for <iframe> in the ready check, but I guess now Microsoft ships an "iframe fullscreen flag" we should just go with that

[23:47:59.0000] <annevk>
philipj: also, is it a problem the specification does not deal with <frame>, <object>, and <embed> in some way?

[23:48:22.0000] <annevk>
I guess those don't support allowfullscreen

[00:08:02.0000] <philipj>
annevk: I would be quite happy just ignoring the iframe.requestFullscreen() followed by elementInIframe.requestFullscreen() problem

[00:08:12.0000] <philipj>
I do wonder if it's been an issue in reality

[00:08:33.0000] <annevk>
Unless my fix is wrong, it does seem relatively easy to fix

[00:09:16.0000] <philipj>
annevk: I don't think <frame> and friends matter, there was support in WebKit/Blink that was removed,

[00:09:48.0000] <philipj>
I have seen one bug report where the reason fullscreen didn't work was because of <frame>, though

[00:10:31.0000] <philipj>
annevk: fixing it with a flag is fine too, since apparently Microsoft was concerned enough to invent their own solution without telling anyone

[00:12:15.0000] <annevk>
philipj: did you ever look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=16502?

[00:13:00.0000] <annevk>
philipj: yeah, my thinking was that since they went through the trouble of implementing that and telling us about it (somewhat belatedly) it's okay for us to accept the cost this one time

[00:13:35.0000] <philipj>
annevk: I have seen that bug, but am not sure what to make of it.

[00:13:38.0000] <annevk>
philipj: although if they keep doing it that way I won't be as nice about it I think

[00:14:08.0000] <annevk>
philipj: I guess I'll wait to see if the Presentation API folks have anything to say

[00:14:21.0000] <philipj>
annevk: Trying to close all Bugzilla bugs are you?

[00:14:34.0000] <annevk>
Yeah, was thinking of marking the other one MOVED

[00:14:49.0000] <annevk>
but I guess I can wait a little longer, there's no particular rush

[00:15:05.0000] <philipj>
Yep

[00:18:24.0000] <philipj>
annevk: it might interest you to know that there's something weird going on with optional arguments and addEventListener()

[00:18:54.0000] <philipj>
All of the arguments are optional in Blink, an attempt to fix it a long time ago was reverted due to something breaking, and now the use counters don't look very promising.

[00:19:13.0000] <philipj>
I don't suppose you've seen any reports in Gecko about this?

[00:22:12.0000] <annevk>
philipj: nope

[01:02:51.0000] <MikeSmith>
philipj: a servo guy who was trying to run the wpt DOM ChildeNode tests today was wondering why https://codereview.chromium.org/1234813003/ was reverted

[01:03:28.0000] <MikeSmith>
(the related wpt tests came from blink upstream, from that changeset)

[01:03:53.0000] <MikeSmith>
that review cites https://code.google.com/p/chromium/issues/detail?id=509461

[01:04:02.0000] <Ms2ger>
@@unscopeables?

[01:04:16.0000] <MikeSmith>
philipj: but I get a 403 trying to view that bug so I assume it's a security issue

[01:06:12.0000] <philipj>
MikeSmith: it introduced a crash which is being fixed, not a problem with the spec if that's the concern

[01:07:37.0000] <MikeSmith>
philipj: ah yeah maybe he had been wondering if it was spec issue

[01:08:05.0000] <MikeSmith>
anyway thanksーI'll pass on the info if/when I chat with him

[01:08:11.0000] <philipj>
MikeSmith: np

[01:12:20.0000] <frewsxcv>
Thanks for the info philipj

[01:12:30.0000] <frewsxcv>
/me is the 'servo guy'

[01:13:27.0000] <philipj>
frewsxcv: are Nodes refcounted in Servo or what's the general story for keeping them alive across an event dispatch that may run GC?

[01:13:37.0000] <Ms2ger>
Garbage collection!

[01:14:32.0000] <Ms2ger>
https://github.com/servo/servo/blob/7235500db6778371abe1d1f727a6d0b24205d5c5/components/script/docs/JS-Servos-only-GC.md

[01:14:46.0000] <Ms2ger>
Not entirely up-to-date (which I should fix), but fairly

[01:15:00.0000] <philipj>
Then you will not have the particular crash we did :)

[01:16:01.0000] <Ms2ger>
We should be entirely safe :)

[01:16:15.0000] <philipj>
I presume that having the equivalent of a this pointer on the stack will also protect it from GC?

[01:16:15.0000] <Ms2ger>
Were those mutation events?

[01:16:21.0000] <frewsxcv>
Last words by every software developer...

[01:16:39.0000] <Ms2ger>
Yeah

[01:16:43.0000] <philipj>
Ms2ger: I don't remember, but seems likely.

[01:16:57.0000] <philipj>
mutation events FTW

[01:17:03.0000] <Ms2ger>
Fortunately we don't have those either :)

[01:18:15.0000] <philipj>
Ms2ger: Feel like removing them in Gecko?

[01:18:21.0000] <MikeSmith>
wow https://github.com/servo/servo/blob/7235500db6778371abe1d1f727a6d0b24205d5c5/components/script/docs/JS-Servos-only-GC.md is nice stuff

[01:18:28.0000] <philipj>
UseCounter says no: https://www.chromestatus.com/metrics/feature/timeline/popularity/144

[01:18:35.0000] <Ms2ger>
Ohgodno

[01:19:57.0000] <MikeSmith>
sad

[01:20:09.0000] <MikeSmith>
how high those numbers are stil

[01:21:14.0000] <philipj>
That's the highest of them, but even the lowest isn't negligible: https://www.chromestatus.com/metrics/feature/timeline/popularity/146

[01:24:11.0000] <MikeSmith>
doubly sad

[01:24:42.0000] <MikeSmith>
wait but that's below 0.03 at least

[01:26:23.0000] <MikeSmith>
also JS-Servos-only-GC.md is nicely worded

[01:26:28.0000] <MikeSmith>
Ms2ger: who wrote that?

[01:27:04.0000] <MikeSmith>
"Josh Matthews and Keegan McAllister"

[01:27:11.0000] <Ms2ger>
Yep

[01:27:34.0000] <Ms2ger>
With a little editing from me, but mostly them

[01:27:40.0000] <MikeSmith>
ok

[01:27:55.0000] <MikeSmith>
good on you as well then

[01:29:13.0000] <Ms2ger>
Maybe I should finish it toay

[01:41:40.0000] <hugoh>
window move up

[01:42:21.0000] <Ms2ger>
Hey! Where'd my window go?

[01:43:06.0000] <hugoh>
sorry! forgot the /

[03:00:11.0000] <annevk>
philipj: we might be able to change mutation event timing

[03:00:27.0000] <annevk>
philipj: e.g. give them the same timing as custom element callbacks

[03:18:36.0000] <smaug____>
except DOMNodeRemoved

[03:19:25.0000] <annevk>
smaug____: what do you mean?

[03:19:33.0000] <annevk>
smaug____: note that DOMNodeRemoved has much less usage too

[03:19:48.0000] <smaug____>
DOMNodeRemoved happens before the mutation

[03:19:49.0000] <annevk>
smaug____: btw, I can't get blur to dispatch at all in Gecko for removed nodes

[03:20:17.0000] <smaug____>
known issue, IIRC

[03:20:21.0000] <annevk>
smaug____: sure, per "spec" most of them fire at rather problematic times

[03:20:21.0000] <smaug____>
though

[03:20:22.0000] <smaug____>
hmm

[03:20:38.0000] <smaug____>
though, we do have code which should trigger blur

[03:21:20.0000] <smaug____>
annevk: so the plan is now to have sync ctors?

[03:21:25.0000] <smaug____>
for custom elements?

[03:21:31.0000] <annevk>
smaug____: <p>x<input onblur=alert(1) onfocus=this.parentNode.remove()> is my test

[03:21:45.0000] <annevk>
smaug____: we don't have a plan yet

[03:22:33.0000] <smaug____>
annevk: could you file a bug. CC enndeakin too

[03:22:37.0000] <annevk>
smaug____: Google would really like to avoid more synchronous JavaScript during DOM and editing algorithms

[03:22:47.0000] <smaug____>
right

[03:23:15.0000] <annevk>
smaug____: so the current plan is exploring whether blur and beforeunload can be made to dispatch using custom element callback timing

[03:23:16.0000] <Ms2ger>
I don't think we'd mind that either

[03:23:16.0000] <smaug____>
I was also thinking that maybe we could postpone blur/beforeunload happening during range operations to happen on nanotask

[03:23:22.0000] <annevk>
(which is better than script runners)

[03:23:28.0000] <smaug____>
and selection operations would be a nano task or something

[03:23:31.0000] <annevk>
right, nanotask

[03:23:46.0000] <annevk>
the thing that doesn't run during compound range operations either

[03:24:20.0000] <smaug____>
/me doesn't know what is the difference between "custom element callback timing" and script runners

[03:24:27.0000] <annevk>
smaug____: DOM component?

[03:24:40.0000] <annevk>
smaug____: afaik script runners run during a single range operation

[03:24:53.0000] <annevk>
smaug____: nanotask is always at the end of an IDL method or attribute

[03:25:11.0000] <smaug____>
script runners run when the outermost script blocker goes away from the stack

[03:25:28.0000] <annevk>
I don't know what that means

[03:25:28.0000] <smaug____>
there can be nested script blockers

[03:26:13.0000] <smaug____>
In C++ you have ScriptBlocker object on stack. When it is created, scriptblocking level is increased

[03:26:25.0000] <smaug____>
when that object is deleted, level is decreased

[03:26:35.0000] <smaug____>
and when level becomes 0, scriptrunners run

[03:26:53.0000] <annevk>
I understand that much, but it's unclear whether they can run during https://dom.spec.whatwg.org/#dom-range-extractcontents for instance

[03:26:54.0000] <smaug____>
those script runners which were posted while the level was != 0

[03:27:11.0000] <smaug____>
currently yes

[03:27:24.0000] <annevk>
right, which makes them less safe than nanotasks

[03:27:39.0000] <smaug____>
annevk: but we could effectively put a scriptblocker to selection/editing level code

[03:27:40.0000] <annevk>
not sure why we keep revisiting this discussion :-)

[03:27:53.0000] <smaug____>
scriptblockers are nanotasks

[03:28:08.0000] <annevk>
not if they run during an IDL block

[03:28:27.0000] <smaug____>
well, in gecko we'd just put scriptblock in the idl block then

[03:28:32.0000] <smaug____>
scriptblocker

[03:29:16.0000] <smaug____>
sure, currently ScriptBlockers are used somewhat ad hoc in Gecko

[03:29:18.0000] <annevk>
once you've made that change we can start calling them nanotasks too

[03:29:22.0000] <annevk>
until that time the distinction is useful

[03:29:27.0000] <smaug____>
sure

[03:31:57.0000] <annevk>
smaug____: https://bugzilla.mozilla.org/show_bug.cgi?id=1187848

[03:32:57.0000] <smaug____>
thanks

[03:33:12.0000] <smaug____>
/me wonders how this nanotask approach will deal with DOMNodeRemoved

[03:46:37.0000] <annevk>
smaug____: https://github.com/whatwg/dom/issues/57 has some details from Edge

[03:46:57.0000] <annevk>
smaug____: seems they do some other things for tree operations compared to other browsers

[04:06:19.0000] <philipj>
annevk: looks like custom element callbacks are kind of like microtasks but their processed at the boundary between native and script?

[04:06:47.0000] <annevk>
philipj: only the return boundary

[04:07:37.0000] <annevk>
philipj: the nickname nanotasks came from that being possible multiple times within a microtask

[04:08:12.0000] <philipj>
s/their/they're/ unforgivable typo

[04:11:13.0000] <philipj>
annevk: would there be any benefit to delaying these callback ever so slightly?

[04:17:42.0000] <annevk>
philipj: "these"?

[04:18:01.0000] <philipj>
annevk: mutation events I mean

[04:18:28.0000] <annevk>
philipj: yes, all the code that deals with mutation events changing the world view would go away

[04:18:58.0000] <annevk>
philipj: and any undiscovered security bugs in those paths would go away too

[04:22:20.0000] <philipj>
annevk: well, that does sound nice, but mutation events have been annoying for a long time, is any browser willing to attempt the change?

[04:22:34.0000] <annevk>
philipj: it seems Blink is

[04:22:53.0000] <annevk>
philipj: see also https://github.com/whatwg/dom/issues/57

[04:23:00.0000] <philipj>
perhaps I'm overestimating the amount of interop there currently is for these events

[04:24:32.0000] <annevk>
philipj: it seems Edge has a somewhat different model per that issue

[04:25:43.0000] <philipj>
Yeah...

[04:25:56.0000] <philipj>
Some details on that would be nice.

[04:26:23.0000] <philipj>
Like how would those invariants be enforced, what is it that causes a nested removeChild() call to fail, etc.

[04:26:35.0000] <annevk>
"https://bugzilla.mozilla.org/show_bug.cgi?id=559561 is pretty ugly

[04:27:37.0000] <philipj>
It would be interesting to know how common it is for mutation event listeners to actually mutate the DOM again

[04:28:15.0000] <philipj>
And if it isn't common at all, if there's a cheap check that could be done to simply disallow that.

[04:28:25.0000] <philipj>
That would make the problems go away I suppose.

[04:28:53.0000] <smaug____>
Gecko fires non-DOMNodeRemoved mutation events using script runners, so if nano task gets defined, and gecko makes a nano task to be a script blocker, non-DOMNodeRemoved would be fired a bit later in editor/selection case

[04:30:32.0000] <annevk>
and range case

[04:31:06.0000] <smaug____>
right

[04:31:53.0000] <annevk>
so we only run complicated code for DOMNodeRemoved at the moment? and for range operations?

[04:31:58.0000] <annevk>
hmm

[04:32:23.0000] <annevk>
I guess that's still less than if custom elements could run code in a bunch of these places

[04:32:59.0000] <annevk>
And I guess DOMNodeRemoved firing after is problematic because the tree is gone

[04:33:22.0000] <annevk>
You'd have to do something weird to notify parents

[04:34:12.0000] <smaug____>
sync custom element ctor case would add yet another new problematic case, cloneNode

[04:35:56.0000] <annevk>
smaug____: if you already need to code defensively for insertions and removals, is cloning making it much worse?

[04:36:23.0000] <smaug____>
perhaps not much. But it is yet another case

[04:37:01.0000] <smaug____>
maybe we'd be better with cloneNode than we were with other cases

[04:37:44.0000] <smaug____>
but would be nice to remove the sync stuff from everywhere

[04:37:49.0000] <smaug____>
that would simplify code

[04:37:57.0000] <smaug____>
...but DOMNodeRemoved...

[04:38:04.0000] <annevk>
no disagreement there

[04:38:32.0000] <smaug____>
/me kicks DOM WG around DOM 2 Events era ;)

[04:38:57.0000] <annevk>
I'm somewhat surprised they got away with just specifying these events without defining their processing model

[04:40:17.0000] <smaug____>
"processing model" in the web before 2004?

[04:42:49.0000] <annevk>
hah

[06:21:41.0000] <wanderview>
annevk: should <applet> be considered a potential client request?

[06:21:54.0000] <annevk>
wanderview: no

[06:22:04.0000] <annevk>
wanderview: though <applet> is underspecified

[06:22:24.0000] <wanderview>
annevk: should it be intercepted?  (I guess I need to ask Matt what chrome does)

[06:22:30.0000] <annevk>
wanderview: it's unclear whether Java does the fetch or the browser and whether all Java fetches are browser-mediated

[06:22:54.0000] <annevk>
wanderview: there's one open bug against HTML on this, which blocks defining an "applet" context

[06:23:56.0000] <wanderview>
annevk: if we have no applet context, that implies to me we should not intercept... safe thing to do for now

[06:28:10.0000] <annevk>
wanderview: we should probably work through the <object> and <embed> cases some more too

[06:28:24.0000] <wanderview>
annevk: well, for now they are spec'd not to be intercepted

[06:28:37.0000] <wanderview>
which is at least not a security problem

[06:32:05.0000] <wanderview>
annevk: I guess its an interesting question for things like amazon.com... they have tons of <object> tags... would they have to rewrite their site to offline it?

[06:32:24.0000] <annevk>
wanderview: yeah

[06:32:36.0000] <annevk>
wanderview: the problem with <object> is that its both a client and resource context

[06:33:00.0000] <annevk>
wanderview: so you don't really know what service worker to use until after you got the response...

[06:33:20.0000] <annevk>
(if that sounds confusing, it's because it is)

[06:33:40.0000] <wanderview>
annevk: its ok... I put it in the bucket of "try to understand after we ship v1" for now

[06:33:57.0000] <annevk>
<applet> doesn't really have that problem, but I'm fine deferring all plugin-like stuff for a bit

[06:34:20.0000] <wanderview>
yea, makes sense

[06:34:28.0000] <annevk>
It does sound like Gecko at least manages some of the <applet> requests so I guess I should define a context for it

[06:34:40.0000] <annevk>
I wonder if anyone can confirm whether that's the case in Chrome too; beverloo maybe?

[06:35:04.0000] <annevk>
Perhaps mkwst is online? \o/

[06:35:07.0000] <wanderview>
annevk: I asked Matt Falkenhagen (irc name?)

[06:35:24.0000] <annevk>
I think matto

[06:35:25.0000] <wanderview>
he said he would help dig up chrome's behavior for this stuff last week

[06:35:46.0000] <annevk>
or maybe his last name, not sure

[06:35:52.0000] <wanderview>
of course... timezones

[06:36:27.0000] <annevk>
in theory he's had his first work day, but maybe he took a day off, dunno

[06:36:43.0000] <mkwst>
Hi! Scrolling back, but the question isn't clear to me. What do you want to know about applet?

[06:37:05.0000] <annevk>
mkwst: basically whether Chrome or Java is in control of fetching

[06:37:06.0000] <wanderview>
well, I just sent him the email... he's probably just going to bed now :-)

[06:37:15.0000] <mkwst>
(other than that Sun doesn't seem to be publishing a PPAPI version of Java so maybe we can kill the tag entirely?)

[06:37:15.0000] <annevk>
aah

[06:37:26.0000] <wanderview>
mkwst: does chrome do any service worker interception for <applet>

[06:37:26.0000] <annevk>
(that'd be great)

[06:37:59.0000] <annevk>
well that's a different question, but I agree it would be good to know the answer to that one too

[06:38:10.0000] <mkwst>
We certainly trigger the request for the applet itself in Blink, and I suspect we have control over the whole request now that we've killed NPAPI.

[06:38:47.0000] <mkwst>
But, again, that's fairly theoretical, as I don't think there's any way of running Java in Chrome in Canary. Maybe even stable, I've lost track...

[06:39:04.0000] <mkwst>
For object and embed it's the same story, except insofar as Flash can open sockets.

[06:39:24.0000] <mkwst>
Sockets are outside Fetch, so it can do pretty much whatever it likes with the connection.

[06:39:24.0000] <annevk>
mkwst: https://java.com/en/download/faq/chrome.xml claims it is still available

[06:39:36.0000] <annevk>
mkwst: outside of Linux, anyway

[06:40:13.0000] <annevk>
Ooh, that actually tells people to switch the NPAPI flag...

[06:40:19.0000] <mkwst>
We might have killed the flag by now.

[06:40:20.0000] <wanderview>
well, object and embed are explicitly not sw intercepted per the current spec

[06:40:57.0000] <mkwst>
wanderview: Sure. I don't know off the top of my head whether the folks responsible for SW set the bypass flags when making requests. Give me a sec.

[06:41:00.0000] <annevk>
wanderview: you're saying that Gecko is also in control over the fetch for <applet>, right?

[06:41:37.0000] <wanderview>
annevk: I haven't looked, but this bug implies it does: https://bugzilla.mozilla.org/show_bug.cgi?id=1187766

[06:41:46.0000] <annevk>
mkwst: https://github.com/whatwg/fetch/issues/73 is blocking on you

[06:42:14.0000] <annevk>
mkwst: https://github.com/whatwg/fetch/issues/52 too

[06:42:28.0000] <annevk>
mkwst: and https://github.com/whatwg/fetch/issues/45

[06:43:02.0000] <wanderview>
annevk: you mentioned to me somewhere that sicking suggested redesigning context to better handle navigation/worker/client concepts...  but you said it was too late... why is it too late?

[06:43:26.0000] <annevk>
wanderview: I figured since Chrome shipped we might not want to change context

[06:43:37.0000] <wanderview>
annevk: I don't think they implement .context yet

[06:43:39.0000] <wanderview>
just a sec

[06:43:43.0000] <annevk>
wanderview: sicking argued that we basically wanted a single context for everything that creates a browsing context

[06:43:58.0000] <annevk>
wanderview: and have a distinct flag for "comes from a form" that CSP can use

[06:44:14.0000] <wanderview>
annevk: they are just implementing it now: https://code.google.com/p/chromium/issues/detail?id=455116

[06:44:44.0000] <annevk>
hmm okay

[06:45:03.0000] <wanderview>
annevk: not that I really want to rewrite a bunch of stuff... ehsan might be annoyed :-)

[06:45:11.0000] <wanderview>
but if its really better... we should consider it

[06:45:42.0000] <annevk>
wanderview: this would only be for all contexts that mean "navigation"

[06:46:00.0000] <annevk>
I guess I can investigate then, although I hope that doesn't cost too much time :/

[06:46:13.0000] <wanderview>
ah, that sounds like less of a change

[06:47:04.0000] <wanderview>
annevk: if you have higher priority stuff... I don't think having the more granular values we do now is bad...  just need this extra "is it a navigation" helper

[06:47:10.0000] <mkwst>
annevk: blocking on me is a seriously bad idea because I am overloaded and behind on everything. But I'll comment on the bugs anyway. :)

[06:47:36.0000] <annevk>
mkwst: is there a qualified fallback person?

[06:47:49.0000] <annevk>
mkwst: this is what you get with all those "small" specs :p

[06:47:50.0000] <wanderview>
mkwst: given that... if you are busy don't worry about the applet... I emailed mattto about it

[06:48:01.0000] <mkwst>
I think I'm abarth's qualified fallback person.

[06:48:37.0000] <annevk>
mkwst: we can't have abarth' go MIA too :p

[06:49:09.0000] <annevk>
maybe I should ask fishd about abarth''

[06:49:23.0000] <wanderview>
annevk: should the SW spec be doing stuff like step 11 here?  or should that be in fetch: http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#on-fetch-request-algorithm

[06:50:28.0000] <annevk>
wanderview: I think that's fine

[06:50:40.0000] <annevk>
wanderview: everything about picking a service worker is left up to SW

[06:50:54.0000] <wanderview>
ok

[06:51:07.0000] <wanderview>
seems security related which makes me think of those other checks in fetch

[06:52:26.0000] <annevk>
I think at some point we might need to figure out the layering again, but for now let's leave it like this

[06:52:54.0000] <annevk>
In general anything Fetch being part of service workers directly is somewhat dirty from a layering perspective

[06:53:34.0000] <wanderview>
annevk: well, looking at public attributes on Request should be ok

[06:53:54.0000] <wanderview>
its just annoying to spread security checks between specs where not necessary

[06:54:26.0000] <wanderview>
/me goes to fetch a baby.

[06:54:58.0000] <annevk>
wanderview: oh, I guess it should not look at the public properties

[06:55:07.0000] <annevk>
wanderview: that seems bad

[06:55:35.0000] <annevk>
wanderview: and I agree with that, but this is about deciding where to handle the fetch, it's not a decision on the response

[06:55:56.0000] <annevk>
wanderview: where to handle the fetch is not really a security decision per se

[06:58:09.0000] <annevk>
mkwst: ta

[07:00:22.0000] <mkwst>
annevk: I'm a seriously poor abarth`. At least, I have been this quarter, and August isn't looking any better. Hopefully the next one will be better.

[07:01:57.0000] <annevk>
mkwst: it's alright, the only thing that's making me nervous is wanderview alluding to us not shipping service workers due to CSP not being ready

[07:02:10.0000] <mkwst>
what, what?

[07:02:19.0000] <mkwst>
who would be crazy enough to do that? :)

[07:02:48.0000] <annevk>
I guess we'll have to wait for wanderview to confirm or deny

[07:04:05.0000] <mkwst>
Tell me what pieces of CSP are blocking SW, and I will make them go away. Unless it's "This doesn't make sense in terms of Fetch.", in which case, yes, I know, and ugh and I'm working on it. Slowly.

[07:06:12.0000] <JakeA>
annevk: going to go through https://github.com/whatwg/fetch/issues/79 while I've got a spare moment. Anything else that's particularly blocking?

[07:07:18.0000] <annevk>
JakeA: no not really

[07:08:05.0000] <annevk>
mkwst: well one issue we have is that it's unclear what the CSP check on responses will be and indeed whether the service worker can set CSP, etc.

[07:08:43.0000] <annevk>
mkwst: there's a great many unanswered questions, but perhaps I'm wrong about that blocking us shipping though

[07:08:52.0000] <annevk>
need to ask wanderview

[07:09:00.0000] <wanderview>
I'm back

[07:09:19.0000] <wanderview>
mkwst: annevk: I believe some form of CSP is a blocker for use service workers in firefoxos

[07:09:22.0000] <annevk>
JakeA: I mean, there's a great number of things I'd like to see resolved, such as range requests

[07:09:27.0000] <wanderview>
which means its a near time requirement for us

[07:10:35.0000] <wanderview>
mkwst: annevk: specifically... being able to say if src is constrained to a server... synthetic responses are not allowed... so you can't bypass the no-eval restrictions

[07:11:48.0000] <JakeA>
annevk: as in, how they appear in a fetch event, how a complete response may be handled, what the cache returns in response to a range, should the browser accept range parts from different sources?

[07:12:13.0000] <annevk>
JakeA: yeah, those type of questions

[07:12:32.0000] <annevk>
JakeA: media elements already make them, so I guess to some extent browsers handle them already

[07:13:28.0000] <JakeA>
yeah, and it feels like having a cache able to produce partial results would be the most compatible and performant way to deal with those

[07:14:05.0000] <annevk>
makes sense

[07:17:11.0000] <wanderview>
I wonder if this overlaps with returning partial responses that are still streaming in for cache.match() of "fetching entry"

[07:21:53.0000] <JakeA>
wanderview: not sure… we wouldn't want to return an http partial response in response to a non-range request

[07:22:04.0000] <JakeA>
I think that'd be a failure case

[07:22:15.0000] <JakeA>
although we might have some magic the other way around

[07:22:27.0000] <wanderview>
JakeA: I guess the question becomes... do partial responses become a combined complete response when all the pieces are cached?

[07:23:08.0000] <JakeA>
if the request is a range, and I respond with new Response("hello world"), should SW or Fetch attempt to create an appropriate partial response (I think it should)

[07:24:25.0000] <JakeA>
wanderview: ohh I see. Yeah, that seems really difficult. We could reject in that case

[07:24:25.0000] <wanderview>
oh... so Cache stores the whole thing... but might slice it given a range request?

[07:24:37.0000] <JakeA>
yeah, that's what I was thinking

[07:24:38.0000] <wanderview>
that seems reasonable

[07:24:59.0000] <JakeA>
/me ponders

[07:25:26.0000] <wanderview>
JakeA: I guess I'm trying to understand what to do in a read-through-cache scenario where a partial request comes... what gets stored in the cache

[07:25:36.0000] <JakeA>
yeah, I'm thinking the same

[07:25:51.0000] <wanderview>
aren't you on PTO?

[07:26:28.0000] <JakeA>
yeah but all my friends are asleep so I'm stuck with you guys

[07:26:29.0000] <JakeA>
:D

[07:26:38.0000] <wanderview>
ha

[07:27:24.0000] <JakeA>
so, cache.put(videoRequest.url, fetch(videoRequest.url)).then(r => {)

[07:27:26.0000] <JakeA>
shit

[07:27:30.0000] <JakeA>
hit enter too soon

[07:28:03.0000] <JakeA>
cache.put(videoRequest.url, fetch(videoRequest.url)).then(_ => cache.get(videoRequest))

[07:28:08.0000] <wanderview>
JakeA: do range requests become less important once we get real streams?

[07:29:14.0000] <wanderview>
because that snippet of code seems reasonable in a Stream API world

[07:29:36.0000] <wanderview>
(if requiring some work to implement)

[07:30:14.0000] <JakeA>
The above would work if the user watched the video sequentially. But if they scrubbed, they'd be waiting for the sequential download to catch up, which isn't great.

[07:30:34.0000] <wanderview>
right, ok

[07:30:44.0000] <JakeA>
wanderview: with streams, wouldn't there be a lot of code effort to turn those into range responses?

[07:30:58.0000] <JakeA>
I guess the question is whether the cache should be that high level

[07:31:34.0000] <JakeA>
(I'm thinking it should)

[07:31:50.0000] <wanderview>
maybe we should just look at what http cache offers

[07:32:02.0000] <wanderview>
if it just treats ranges as any other request

[07:32:05.0000] <wanderview>
or if it does magic

[07:34:55.0000] <annevk>
note that for at least some media, we seek to the last set of bytes

[07:35:02.0000] <annevk>
some containers are broken like that

[07:35:14.0000] <annevk>
ideally we cleanly handle all those scenarios

[07:35:50.0000] <wanderview>
section 13.5.4 here suggests that combining is allowed per the spec... who knows if anyone implements it: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

[07:36:17.0000] <annevk>
and streams doesn't solve seek and such

[07:36:24.0000] <wanderview>
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.5.4

[07:36:27.0000] <annevk>
I think we're stuck with both

[07:38:17.0000] <wanderview>
JakeA: I think I might just make the Cache API matching algorithm include range comparisons so they are unique... and then offer a .merge(reqList) to combine them if the client code wants

[07:38:30.0000] <wanderview>
so read-through-caching works

[07:38:37.0000] <wanderview>
if they want to optimize and merge they can

[07:38:56.0000] <wanderview>
and then do your auto-slicing thing on match

[07:39:04.0000] <annevk>
can't we auto-merge them?

[07:40:02.0000] <wanderview>
annevk: it seems to me we try to let script control how the Cache works instead of being magical like http cache

[07:40:13.0000] <wanderview>
so I'd rather give them an API to do it if they want

[07:40:19.0000] <annevk>
wanderview: hmm, the Cache API is fairly high-level

[07:40:31.0000] <annevk>
wanderview: e.g. the whole match algorithm

[07:40:34.0000] <annevk>
for starters

[07:40:51.0000] <wanderview>
annevk: but we explicitly don't do any *modification* of the cache automatically... its all script controlled

[07:41:43.0000] <annevk>
I guess, but it does seem fairly silly if range requests/responses require a bunch of make work whereas everything else just works

[07:42:20.0000] <wanderview>
annevk: the rfc suggests you don't always want to merge... if one part of the range is newer than the rest, etc

[07:43:09.0000] <wanderview>
anyway... happy to let Jake figure this out while his friends are asleep :-)

[07:43:36.0000] <annevk>
I mean, in that case it says you must discard the older bits

[07:43:54.0000] <annevk>
If they're not equivalent cache-wise

[07:44:07.0000] <wanderview>
annevk: and we explicitly don't discard things automatically in Cache API...

[07:44:29.0000] <wanderview>
the whole point of the API was to let the script decide

[07:45:01.0000] <annevk>
fair, but sounds fairly complicated to combine that with ranges

[07:45:06.0000] <annevk>
and keep the API convenient

[07:46:12.0000] <wanderview>
they can .match() all the ranges, manually combine into a new Response, and then Cache put it back... the .merge() was a convenience to do that efficiently in the platform

[07:47:20.0000] <annevk>
you're assuming ranges are non-overlapping

[07:48:05.0000] <wanderview>
am I? it would be a pain, but script could do it with current primitives

[07:48:59.0000] <annevk>
or maybe you're saying I need to make a side-table to store all the ranges

[07:49:21.0000] <annevk>
it's not entirely clear to me how  to get ranges out of the cache if all I have is a URL

[07:50:07.0000] <wanderview>
oh... well that would need to be added, yea...  I thought we were talking about a world where you could pass range requests to .match()

[07:51:45.0000] <wanderview>
anyway, if it can be done automatically without losing data then thats cool with me

[07:53:53.0000] <JakeA>
I'm kinda happy with cache being high level, hopefully idb will become the place to do it if you need lower level

[07:54:01.0000] <JakeA>
but I need to think about it more

[07:56:23.0000] <wanderview>
annevk: why do we even have CORS responses if they can be so easily converted to synthetic responses?  should we just have one type?

[07:57:06.0000] <annevk>
wanderview: https://fetch.spec.whatwg.org/#concept-filtered-response-cors

[07:57:21.0000] <wanderview>
prevents copying the headers I guess

[07:57:49.0000] <annevk>
if you ignore some set of data, everything is the same type

[07:58:16.0000] <annevk>
that's how you end up with == and security bugs

[07:59:42.0000] <wanderview>
yea, I forgot about the headers... seems we spend all our time worrying about cross-origin body content

[08:00:20.0000] <annevk>
that's also what leads people to think ReadableStream is all we need

[08:00:27.0000] <annevk>
might even be the same people

[08:00:32.0000] <annevk>
:-P

[08:01:40.0000] <annevk>
(I didn't follow that navigation attack scenario from JakeA btw, seems wrong?)

[08:03:48.0000] <JakeA>
annevk: Am I right in thinking the attack is exposed when a client request is made to the "infected" url?

[08:04:05.0000] <JakeA>
that's when the cross-origin code is executing

[08:05:21.0000] <JakeA>
The bad stuff goes into the cache via a cors request, and comes back out via a client request - that was my understanding, but I haven't seen the attack work (in a while) so I'm not sure

[08:07:11.0000] <annevk>
JakeA: oh wait, the Cache API would follow redirects whereas navigation doesn't?

[08:07:41.0000] <annevk>
JakeA: yeah, I think the Cache API is somewhat broken here, in storing the redirected response but still with the original request URL...

[08:08:41.0000] <JakeA>
annevk: the cache would end up with an entry where the key was "good site" and the value was "bad site". Then when the navigation happens, the "bad site" entry is pulled out

[08:08:52.0000] <JakeA>
I mean, they can both be synthetic

[08:08:58.0000] <annevk>
JakeA: yeah, understood

[08:09:01.0000] <wanderview>
Cache API should store the final URL property on the Response, no?

[08:09:08.0000] <JakeA>
yeah

[08:09:09.0000] <annevk>
JakeA: that seems like a problem with usage of the Cache API

[08:09:25.0000] <annevk>
JakeA: or design of the Cache API...

[08:10:05.0000] <annevk>
JakeA: it should be some kind of explicit action to persist a redirect in the cache

[08:10:06.0000] <JakeA>
I mean, if we're nervous about it, we could consider rejecting if the request/response have different origins. You could still do it with synthetics though

[08:10:23.0000] <annevk>
A synthetic is explicit

[08:10:34.0000] <annevk>
Different origins seems ugly

[08:10:56.0000] <annevk>
And doesn't work for same-origin -> cross-origin -> same-origin

[08:11:00.0000] <wanderview>
this would be a breaking change, no?

[08:11:25.0000] <annevk>
Yes

[08:12:02.0000] <wanderview>
annevk: what about fetch(redirectingURL).then(function(response) { cache.put(sameOriginURL, response) }); ?

[08:12:34.0000] <annevk>
wanderview: that's fairly explicit too

[08:12:40.0000] <wanderview>
where the fetch is done external to Cache

[08:12:47.0000] <annevk>
wanderview: we don't even change contexts in that case

[08:12:49.0000] <wanderview>
annevk: so you just want to block redirects in cache.add()?

[08:13:12.0000] <annevk>
wanderview: dunno

[08:14:47.0000] <annevk>
But I don't really think the design of the cache should result in further restrictions in Fetch

[08:14:51.0000] <annevk>
that seems quite backwards

[08:15:04.0000] <annevk>
and not actually solving the problem

[08:15:20.0000] <annevk>
which will popup elsewhere if left unsolved

[08:16:22.0000] <wanderview>
annevk: why does this need Cache API?  can't the service worker just do a fetch(url, {mode: 'cors'}) and respondWith immediately?

[08:16:34.0000] <wanderview>
unclear to me why Cache is relevant here

[08:17:44.0000] <wanderview>
JakeA: why do you need Cache for this?  it seems a standalone fetch() could result in "bad stuff"... which is then returned for a client request

[08:18:39.0000] <JakeA>
wanderview: yeah, but it's the cache that may be making it easier for this to happen by accident

[08:18:51.0000] <JakeA>
right, I'm heading out, just as it was getting interesting. Sorry!

[08:19:04.0000] <wanderview>
JakeA: I guess I was asking in reference to annevk's "I don't really think the design of the cache should result in further restrictions in Fetch"

[09:07:10.0000] <JonathanNeal>
I’m writing about @font-face and type foundries, but I’m having trouble distinguishing between a distributor like “The League of Movable Type” and “Google Fonts”. Both fulfill the definition, but one doesn’t really produce their own fonts. What do I call something like Google Fonts or TypeKit?

[09:17:39.0000] <wanderview>
JakeA: annevk: our http cache behavior for range requests: https://pastebin.mozilla.org/8840726

[09:44:14.0000] <annevk>
JonathanNeal: why not just say that some are X, some are Y, some are both?

[09:44:59.0000] <JonathanNeal>
annevk: I haven’t found anywhere that really does both.

[09:45:05.0000] <annevk>
wanderview: whoa, if you do a range request and you get a 200 we refetch?

[09:45:23.0000] <annevk>
wanderview: I guess that's one case that's not currently considered

[09:45:40.0000] <annevk>
JonathanNeal: so font foundry vs CDN?

[09:46:09.0000] <JonathanNeal>
What I’ve learned (or so I think I’ve learned) is that Google Fonts and TypeKit are “typeface directories”.

[09:46:31.0000] <annevk>
I don't think there's any authority on the terms for those things

[09:46:39.0000] <annevk>
I guess you could look at Wikipedia

[09:47:25.0000] <JonathanNeal>
Yeap, Wikipedia and Googling for some kind of blog consensus. TypeKit never refers to themselves as such, since they describe themselves for their service and not their collection.

[09:47:28.0000] <annevk>
wanderview: also, that seems like an oversimplification, unless we really don't do any validation of the various ranges we have in the cache

[09:48:02.0000] <JonathanNeal>
annevk: and “directory” is a tricky name, since I think of a typeface directory as the place I put my self hosted fonts for a relative path @font-face rule.

[09:48:36.0000] <wanderview>
annevk: it probably is a simplification... but I don't think its surprising that implementations do something simpler that might be faster and less complex to implement

[09:59:27.0000] <annevk>
JonathanNeal: I would just go with font CDN and font foundry personally

[09:59:56.0000] <annevk>
wanderview: or just do something weird :-)

[10:01:04.0000] <JonathanNeal>
annevk: I’ll consider that, yea. I now appreciate how brew abstracted the whole thing to “taps”.

[10:17:28.0000] <wanderview>
annevk: you can always go ask mayhemer to clarify in #necko

[10:17:48.0000] <annevk>
wanderview: I take it you're no longer in #necko :-)

[10:18:08.0000] <wanderview>
annevk: I am... but I don't look at it often... I see you're harassing him now

[10:19:04.0000] <annevk>
wanderview: do you have useful copy-and-paste for IRC?

[10:19:30.0000] <wanderview>
annevk: I just copy to pastebin I guess

[10:19:41.0000] <annevk>
wanderview: would love to have everything from your question down into https://github.com/whatwg/fetch/issues/38 somehow

[10:19:54.0000] <wanderview>
annevk: I'll copy it

[10:20:00.0000] <annevk>
wanderview: but whenever I copy-and-paste the formatting around the nickname goes all bonkers

[10:20:16.0000] <annevk>
ta

[10:20:16.0000] <wanderview>
I think irccloud works ok for this

[10:20:25.0000] <annevk>
LimeChat--

[10:21:24.0000] <wanderview>
done

[10:21:35.0000] <wanderview>
annevk: mozilla instance of irccloud works pretty well

[10:21:56.0000] <annevk>
Yeah, I guess I should switch, mostly been putting it off due to inertia

[10:23:13.0000] <wanderview>
annevk: hmm... it did lose the names on the log when I pasted it

[10:23:50.0000] <wanderview>
I'll fix it

[10:27:17.0000] <wanderview>
annevk: I guess irccloud messed up too... put names in brackets like <bkelly>... which markdown just treats as html and hides

[10:27:40.0000] <annevk>
wanderview: use ``` and ``` around it?

[10:27:55.0000] <annevk>
wanderview: GitHub might even support ```irc for IRC highlighting...

[10:28:22.0000] <wanderview>
annevk: I already modified it to show in markdown

[10:28:55.0000] <annevk>
ait

[10:29:41.0000] <wanderview>
annevk: what does "ait" mean?

[10:29:55.0000] <annevk>
alright

[10:30:16.0000] <wanderview>
ait

[10:30:31.0000] <annevk>
k

[10:37:39.0000] <wanderview>
annevk: if there is a defined RequestContext enum value in fetch... does that mean it should be intercepted?  or just that you think it might be reasonable to intercept if someone wants to spec it?

[10:39:43.0000] <annevk>
wanderview: in principle I think everything should be intercepted

[10:40:54.0000] <wanderview>
annevk: I feel I can usefully take this statement out of context... thanks

[10:45:41.0000] <annevk>
hah

[10:52:01.0000] <hallvors>
/me wants to joke about annevk and the NSA

[10:54:16.0000] <hallvors>
annevk: joking aside, on to spec editing style questions

[10:54:33.0000] <annevk>
evening hallvors

[10:54:51.0000] <hallvors>
I like having a prose description of what we're up to

[10:55:11.0000] <annevk>
hallvors: so one problem with the before* not being integrated is that it's not very clear when they fire in relation to the other events

[10:55:20.0000] <annevk>
hallvors: and whether they fire from different tasks or not

[10:55:27.0000] <hallvors>
aha

[10:55:33.0000] <annevk>
hallvors: and what happens if you launch a copy operation from one of them

[10:55:35.0000] <annevk>
hallvors: etc.

[10:56:04.0000] <hallvors>
there is a "processing model" section for them, but *when* they fire is not spec'ed

[10:56:07.0000] <hallvors>
https://w3c.github.io/clipboard-apis/#processing-model-for-before-events

[10:56:14.0000] <annevk>
hallvors: if you don't have a very clear set of steps, it's super easy to poke holes

[10:57:22.0000] <annevk>
hallvors: so those fiddle with a command state in the end, which requires more than just firing an event

[10:57:29.0000] <annevk>
hallvors: they require execution of some command

[10:57:40.0000] <hallvors>
exactly when to fire them is left up to the implementation.. they aren't really about commands, they are about UI

[10:57:44.0000] <annevk>
hallvors: currently you'd get a nullpointer exception

[10:58:08.0000] <annevk>
hallvors: well presumably they fire in response to some action by the user, from a task

[10:58:31.0000] <hallvors>
I may need a better word than "command"..

[10:59:18.0000] <hallvors>
it's up to the UA when to fire them, but typically it would happen for example when the user opens the "Edit" menu

[10:59:47.0000] <annevk>
ah right, they're unrelated to firing of the non-before events

[11:00:03.0000] <hallvors>
so the UA is about to show the user a menu containing "copy"/"cut"/"paste" commands, and wants to enable or disable them

[11:00:27.0000] <hallvors>
exactly. They are sort of completely unrelated to those other clipboard events..

[11:00:35.0000] <annevk>
so what you actually want to define then is a set of steps for displaying "edit UI"

[11:00:52.0000] <annevk>
And then you have an algorithm whenever you "display edit UI"

[11:01:02.0000] <annevk>
To figure out how you display it

[11:01:12.0000] <annevk>
It happens to run some script from a queued task to figure that out

[11:01:26.0000] <annevk>
Do you get distinct tasks for each event? Or do they share a task?

[11:01:36.0000] <annevk>
That's the kind of thing that should be obvious from that algorithm

[11:01:51.0000] <hallvors>
right

[11:02:12.0000] <hallvors>
/me will report a github issue on the spec

[11:02:40.0000] <hallvors>
spent way too much time on this today already due to git doing things I didn't understand..

[11:02:52.0000] <annevk>
ah sorry :-(

[11:03:03.0000] <annevk>
tooling issues are the worst

[11:03:09.0000] <hallvors>
well, it's not your fault :)

[11:03:18.0000] <hallvors>
I assume :)

[11:03:25.0000] <annevk>
I guess sympathize is a better word

[11:04:09.0000] <hallvors>
thanks! appreciated. I got into some weird state where a submodule was there but wasn't there. somehow.

[11:04:36.0000] <hallvors>
#-]

[11:04:47.0000] <annevk>
I usually lazy-IRC for all git issues I encounter

[11:04:58.0000] <annevk>
There's a surprising number of people on #whatwg who know what's what

[11:05:27.0000] <hallvors>
well, MikeSmith helped me out in irc.w3's#testing

[11:09:00.0000] <annevk>
back later, time for a break

[11:56:43.0000] <ccardona-work>
o/ whatwg

[11:58:42.0000] <wanderview>
writing this blog post is triggering all my worst procrastination tendencies from school

[12:10:32.0000] <JonathanNeal>
Is there a name for the css pattern seen as url(), local(), and format() ?

[12:10:55.0000] <Ms2ger>
Function?

[12:36:51.0000] <TabAtkins>
annevk: Something like "In parallel with the rest of the algorithm, run the following steps:" would work. As it's written, the "in parallel" part is implied to apply over the "following steps" not over the rest of the algorithm as it should be.

[12:37:08.0000] <TabAtkins>
JonathanNeal: Yes, function.  Or functional notation, either works.

[12:38:29.0000] <JonathanNeal>
Thank you, Ms2ger, TabAtkins. :)

[14:32:41.0000] <annevk>
TabAtkins: shrug, file bugs?


2015-07-28
[22:32:51.0000] <TabAtkins>
hallvors: Protip, submodules are the devil and nobody should ever use them.

[22:33:20.0000] <TabAtkins>
git-subtree is a little better, but I'm honestly doing fine with "just git clone the other project in, then delete its .git folder"

[00:33:28.0000] <annevk>
MikeSmith: if it's possible to close a component for new bugs, would be good for WebAppsWG/Fullscreen

[00:33:44.0000] <annevk>
MikeSmith: Fullscreen is GitHub-only now

[01:09:45.0000] <MikeSmith>
annevk: OK, the Fullscreen component should be closed for new bugs now

[01:20:37.0000] <annevk>
Anyone else update https://wiki.whatwg.org/wiki/Specs/todo from time to time?

[01:20:49.0000] <annevk>
I added SVG since it's apparently not maintained much

[01:22:51.0000] <MikeSmith>
annevk: I don't update that but can help with it going forward

[01:23:16.0000] <annevk>
MikeSmith: cool

[01:23:43.0000] <MikeSmith>
annevk: I'd imagine heycam|away might not agree SVG should be included there. Or ed either

[01:24:24.0000] <MikeSmith>
I thought they were actually somewhat actively working on an sorta living SVG spec these days

[01:25:34.0000] <MikeSmith>
annevk: https://svgwg.org/svg2-draft/

[01:25:54.0000] <MikeSmith>
and https://svgwg.org/specs/paths/

[03:34:20.0000] <annevk>
I wrote a summary of the custom elements meeting: https://annevankesteren.nl/2015/07/shadow-dom-custom-elements-update

[03:34:46.0000] <annevk>
I would add some links but I didn't see any links to minutes come by

[03:35:48.0000] <annevk>
Aww, missed the twelve year anniversary of my blog

[03:51:53.0000] <MikeSmith>
annevk: congrats on that 12-year milestone

[03:52:08.0000] <MikeSmith>
annevk: minutes from the f2f at at https://docs.google.com/document/d/1KSwKrTU2d0uJCf55tV-jur_0sYxCNMuM7Dl3vqb0bu4/edit?pli=1

[03:52:13.0000] <MikeSmith>
and at https://www.w3.org/2015/07/21-webapps-minutes.html

[03:52:24.0000] <MikeSmith>
and I think maybe also at https://www.w3.org/2015/07/22-webapps-minutes.html

[03:52:41.0000] <MikeSmith>
or for the W3C links, http instead of https

[03:54:24.0000] <annevk>
I guess the "spans midnight" command was forgotten

[03:54:58.0000] <MikeSmith>
yeah

[03:55:12.0000] <MikeSmith>
but there's not much in that https://www.w3.org/2015/07/22-webapps-minutes.html anwyay

[03:55:27.0000] <MikeSmith>
annevk: "several focus events that fire synchronously"?

[03:58:57.0000] <annevk>
MikeSmith: in some browsers anyway you can get blur events fired when a focused element is removed from the tree

[03:59:16.0000] <annevk>
MikeSmith: same for focusout and there should be some trick for getting that with focusin/focus

[04:03:23.0000] <MikeSmith>
annevk: ok

[04:06:30.0000] <annevk>
nox: regarding https://github.com/whatwg/dom/issues/59#issuecomment-124966988

[04:06:41.0000] <annevk>
nox: how can the previous sibling change if node === child?

[04:07:08.0000] <Ms2ger>
One of these is adopted, so loses its siblings?

[04:08:13.0000] <annevk>
Ms2ger: say we have X, Y, Z as siblings, in order

[04:08:19.0000] <annevk>
Ms2ger: if Y == node == child

[04:08:26.0000] <annevk>
Ms2ger: X is the previous sibling

[04:08:33.0000] <annevk>
Ms2ger: Z is the reference child marker

[04:08:38.0000] <annevk>
Ms2ger: Y is removed

[04:08:47.0000] <annevk>
Ms2ger: then Y is inserted before Z

[04:08:54.0000] <annevk>
Ms2ger: why would X change?

[04:09:08.0000] <Ms2ger>
/me looks at the issue

[04:10:23.0000] <annevk>
Oh you are correct

[04:10:30.0000] <annevk>
We need to set the marker before adopting

[04:10:54.0000] <annevk>
Thanks, that seems to be all

[04:11:06.0000] <Ms2ger>
Np :)

[04:18:06.0000] <annevk>
Ms2ger: have you not hit the problem in Servo where the DOM Standard has basically the wrong internal notifications for remove/insert?

[04:18:35.0000] <annevk>
Ms2ger: https://github.com/whatwg/dom/issues/34

[04:19:19.0000] <Ms2ger>
Yeah

[04:19:47.0000] <Ms2ger>
But that's all a mess in Servo anyway, sadly :/

[04:19:54.0000] <annevk>
Maybe I better fix that then so it doesn't become a problem

[04:19:57.0000] <annevk>
Oh

[04:19:59.0000] <annevk>
That's more like it!

[04:20:20.0000] <annevk>
Is CSS basically the only aspect of Servo that's saner than contemporary browsers?

[04:21:28.0000] <Ms2ger>
I think the DOM isn't that bad, overall, but there's a lot of work still

[04:22:04.0000] <annevk>
I guess I should start looking into 34 since it keeps coming up with custom elements too

[04:22:29.0000] <annevk>
Seems higher priority than merging in parts of Shadow DOM

[04:40:03.0000] <nox>
DOM is getting better and better in Servo.

[04:48:33.0000] <annevk>
Ms2ger: nox: could you review https://github.com/whatwg/dom/issues/34#issuecomment-125571750 perhaps? Although I guess I should ask bz to be sure

[04:48:45.0000] <annevk>
I didn't realize that was such a "trivial" issue to fix

[04:49:26.0000] <nox>
annevk: I'm not sure I get what it is about.

[04:49:33.0000] <nox>
annevk: Is it about insertion/removal steps?

[04:49:45.0000] <annevk>
nox: about them not running for descendants at the moment

[04:50:22.0000] <nox>
I'm not sure we want that.

[04:50:43.0000] <annevk>
You need it if you want to implement e.g. <iframe> properly

[04:50:53.0000] <annevk>
Say you have <p><iframe></iframe></p>

[04:50:55.0000] <annevk>
I remove <p>

[04:50:56.0000] <nox>
<iframe> doesn't use insertion/removing steps.

[04:50:59.0000] <annevk>
Yes it does

[04:51:16.0000] <annevk>
You now need to destroy the <iframe>'s document and global object

[04:51:19.0000] <nox>
It does things on insertion/removal, but IIRC it doesn't explicitly mention this thing.

[04:51:29.0000] <annevk>
For that <p>'s descendants need to be modified

[04:51:36.0000] <annevk>
notified*

[04:51:42.0000] <nox>
Of course, my Internet doesn't want to work…

[04:51:58.0000] <nox>
Why is it always when conversations are interesting that the thing breaks?

[04:52:10.0000] <annevk>
Heh

[04:53:03.0000] <nox>
annevk: <iframe> links to https://html.spec.whatwg.org/multipage/infrastructure.html#remove-an-element-from-a-document

[04:53:11.0000] <nox>
That's not DOM's removing steps, AFAICT.

[04:53:22.0000] <annevk>
nox: eventually it will be

[04:53:31.0000] <annevk>
nox: how else would the world be tied together?

[04:53:41.0000] <nox>
What do yomou vimean

[04:53:48.0000] <nox>
Wow, what do you mean*?

[04:53:54.0000] <annevk>
nox: a bunch of HTML is basically monkey patching DOM due to missing stuff

[04:54:19.0000] <nox>
Mmmh…

[04:54:31.0000] <nox>
I'm pretty sure there are occurences of insertion steps that you don't want as descendants.

[04:55:05.0000] <annevk>
nox: I'm not sure what that means, but tell me this, how would you implement the "removed from a document" requirements using the current set of primitives in the DOM?

[04:55:07.0000] <nox>
annevk: <img> for example,

[04:55:32.0000] <nox>
annevk: I would keep current "insertion steps" as "insertion steps in a parent",

[04:55:41.0000] <nox>
and I would introduce the concept of "insertion steps in a document".

[04:55:54.0000] <nox>
The latter being called on all inclusive descendants.

[04:55:59.0000] <annevk>
nox: that's effectively what this is

[04:56:12.0000] <annevk>
nox: just not scoped to documents, because the notifications in browsers aren't either

[04:56:26.0000] <nox>
I don't understand what you mean.

[04:56:48.0000] <annevk>
nox: if you internet connection is up you might want to follow the links at the top of the issue

[04:57:03.0000] <annevk>
nox: you have both Gecko and Blink folks explaining their internal callbacks

[04:57:44.0000] <nox>
annevk: My problem with this is that you then need to sometimes check whether the node in the insertion and removal steps is actually a top-level node.

[04:57:51.0000] <nox>
That's why I would rather have two different things.

[04:59:26.0000] <annevk>
nox: given that's more complicated and doesn't match existing browsers I doubt that's a better setup

[05:00:02.0000] <annevk>
nox: is this based on the subset of the DOM Servo implements today?

[05:01:14.0000] <nox>
annevk: For example, I care that an <img> was removed as a descendant because I might take this as an opportunity to free memory or whatnot, but I care for different reasons if it is actually removed directly because I might need to do some things if it is removed from a <picture>.

[05:01:42.0000] <nox>
annevk: Currently Servo has bind_to_tree and unbind_to_tree and children_changed.

[05:02:10.0000] <nox>
The first two sound the same as in the first link in the issue, the latter behaves more or less like childList mutations.

[05:02:28.0000] <annevk>
nox: yeah, bind_to_tree / unbind_to_tree are what this bug is about

[05:02:53.0000] <annevk>
nox: children_changed is that mutation observers give

[05:03:04.0000] <nox>
I know, I'm saying they should correspond to "inserted/removed from a document" and that "insertion/removing steps" should be something else.

[05:03:32.0000] <annevk>
I don't see why we'd have four concepts where Servo and every other browser has two

[05:03:38.0000] <nox>
annevk: "The element's parent is a picture element and a source element is inserted as a previous sibling." That sounds complicated to implement if you always need to check in bind_to_tree whether the node as a parent or not.

[05:04:05.0000] <nox>
If a removed <source> element has still a parent when calling unbind_to_tree on it, that means it was removed as a descendant,

[05:04:18.0000] <nox>
if it doesn't have a parent anymore, it was the actual node removed.

[05:04:38.0000] <nox>
Won't conflating the two still need to repeat that every time when actually specifying the steps?

[05:05:21.0000] <annevk>
Some algorithms might need such a check, sure

[05:05:52.0000] <nox>
That's why I don't think it's a good idea to conflate them.

[05:07:12.0000] <annevk>
If that's your only concern I think we'll manage

[05:07:30.0000] <nox>
annevk: How would you reformulate "If a source element is inserted as a child of a media element that has no src attribute and whose networkState has the value NETWORK_EMPTY, the user agent must invoke the media element's resource selection algorithm." when conflating the two?

[05:07:32.0000] <annevk>
We can always separate node and descendant notification later on...

[05:08:11.0000] <nox>
"If the parent passed to insertion steps is equal to the parent of the <source> inserted element, and the parent is a media element (…), the user agent must invoke (…)"?

[05:08:37.0000] <annevk>
seems reasonable

[05:08:47.0000] <nox>
Seems confusing to me.

[05:08:57.0000] <annevk>
if it's common I imagine we might have a shorthand for such a check

[05:09:10.0000] <annevk>
I don't think it's super common though

[05:09:28.0000] <annevk>
the more common case is about document / out-of-document

[05:10:58.0000] <annevk>
Which makes me wonder, anyone know how fast the "in composed tree" check is with the new slots proposal?

[05:12:06.0000] <nox>
annevk: "Specifications may define insertion steps for all or some nodes. The algorithm is passed newNode as indicated in the insert algorithm below."

[05:12:19.0000] <nox>
Then that needs to change too and be passed the parent like in removing steps.

[05:12:42.0000] <nox>
Otherwise you will never know if the node was directly inserted or only as a descendant.

[05:13:55.0000] <annevk>
nox: yeah, it needs an inclusiveAncestorNode

[05:14:21.0000] <nox>
Why inclusive?

[05:14:59.0000] <nox>
annevk: I would just mimic "Specifications may define removing steps for all or some nodes. The algorithm is passed removedNode, oldParent, and oldPreviousSibling, as indicated in the remove algorithm below."

[05:15:40.0000] <nox>
Without oldPreviousSibling because I don't think that's useful for insertion steps.

[05:16:33.0000] <nox>
So "Specifications may define insertion steps for all or some nodes. The algorithm is passed newNode and parent as indicated in the insert algorithm below."

[05:17:25.0000] <annevk>
nox: why do you need parent actually? wouldn't that just be newNode.parent?

[05:17:35.0000] <nox>
annevk: No,

[05:17:43.0000] <nox>
annevk: if I insert a <picture> with an <img> inside,

[05:18:06.0000] <nox>
I don't want that to be considered as a "relevant mutation" for the <img> node.

[05:18:22.0000] <annevk>
nox: <img> would get a callback for being inserted

[05:18:33.0000] <nox>
But it shouldn't change the state of the <picture>.

[05:19:15.0000] <annevk>
nox: that's why browsers hand out these notifications twice I think

[05:19:25.0000] <nox>
I don't understand what you mean.

[05:19:35.0000] <nox>
annevk: If I remove a form from a document,

[05:20:10.0000] <nox>
I don't want the form-associated elements to trigger the parts of their removing steps that alter the form.

[05:20:30.0000] <nox>
I need to know whether an element was inserted/removed itself or as a descendant.

[05:20:51.0000] <nox>
Just passing newNode to the insertion steps doesn't allow that.

[05:20:57.0000] <annevk>
nox: how would that work for a descendant <iframe> of the <form>?

[05:21:10.0000] <nox>
annevk: I don't see how that is related.

[05:21:24.0000] <annevk>
nox: I don't see how insertion steps are related to removing a form

[05:21:48.0000] <nox>
Forget about the form, I'm trying to find a better example.

[05:21:49.0000] <kochi>
 annevk: thanks for the comment on 'delegatesFocus' issue. What's your feeling about how 'delegatesFocus' thing fits in shadow DOM v1?

[05:22:13.0000] <nox>
annevk: https://html.spec.whatwg.org/#relevant-mutations

[05:22:16.0000] <annevk>
kochi: dunno, it wasn't really discussed in the meeting

[05:22:37.0000] <annevk>
kochi: UI input in general is kind of a mess :/

[05:22:48.0000] <nox>
annevk: Am I correct in saying this link does not say anything about inserting in/removing from a document, right?

[05:23:10.0000] <nox>
annevk: If I remove a <picture> that has an <img> child,

[05:23:18.0000] <nox>
Err,

[05:23:27.0000] <nox>
If I insert a <picture> that has an <img> child in a document,

[05:24:22.0000] <nox>
how do I not update the image data of the <img> when its insertion steps are invoked, given I can't know whether they were invoked because the <img> itself was inserted or because its <picture> parent was?

[05:24:32.0000] <annevk>
kochi: and given that most of focus stuff is unexplained when it comes to composed trees... seems hard to add something new

[05:26:08.0000] <nox>
annevk: Let's say I have an element <foo> which insertion steps say "foo inserted in bar" should be logged to the console if its new parent is a <bar> element,

[05:26:11.0000] <annevk>
nox: if <img>'s callbacks run removedNode would be <picture>, which is still <img>'s parent so it has no reason to do anything?

[05:26:20.0000] <nox>
I insert "<bar><foo/></bar>" in the document,

[05:26:47.0000] <nox>
if the insertion steps are invoked for all descendants with only the node, "foo inserted in bar" will be logged and that would be wrong.

[05:27:08.0000] <nox>
annevk: I'm talking about insertion here.

[05:27:20.0000] <nox>
The removal steps can distinguish the two because they are passed oldParent.

[05:28:12.0000] <annevk>
nox: are you assuming the callback needs to be passed the this object?

[05:28:29.0000] <nox>
I don't understand what you mean.

[05:28:48.0000] <annevk>
nox: that it needs a reference to the element for which it was invoked?

[05:28:50.0000] <nox>
I'm saying insertion steps, like removing steps, should be passed the parent of the actually-inserted/removed node.

[05:29:12.0000] <annevk>
why isn't passing the actually-inserted node enough?

[05:29:19.0000] <kochi>
annevk: yeah, currently shadow DOM spec says focus is based on tree-of-trees, not explained in terms of composed tree.

[05:29:21.0000] <nox>
Because of what I just explained.

[05:29:23.0000] <annevk>
you can just query its parent, no?

[05:29:39.0000] <nox>
"Let's say I have an element <foo> which insertion steps say "foo inserted in bar" should be logged to the console if its new parent is a <bar> element, I insert "<bar><foo/></bar>" in the document,  if the insertion steps are invoked for all descendants with only the node, "foo inserted in bar" will be logged and that would be wrong."

[05:29:54.0000] <nox>
I'm saying that insertion steps as defined currently aren't good enough to be invoked on all descendants.

[05:30:33.0000] <nox>
Because contrary to removing steps, you can't include a step that disambiguates insertion-as-actually-inserted-node from insertion-as-descendant-of-actually-inserted-node.

[05:31:55.0000] <annevk>
In your case <foo> is the object for which the callback is invoked, newNode is <bar>, so <foo> knows it's not inserted since then newNode would be <foo>

[05:32:07.0000] <nox>
What?

[05:32:21.0000] <nox>
Aren't we talking about running these steps for all the descendants?

[05:32:32.0000] <annevk>
Yes, but newNode wouldn't change

[05:32:57.0000] <nox>
annevk: Insertion steps have no context object currently AFAICT.

[05:33:29.0000] <nox>
It's just "Run the insertion steps with newNode."

[05:33:33.0000] <annevk>
Yeah, hence I asked before if you were saying that "it needs a reference to the element for which it was invoked?" because that I agree with

[05:33:51.0000] <nox>
Ok. If we actually have two bits of data that makes sense,

[05:33:59.0000] <nox>
now I get why you mentioned "inclusive ancestor node".

[05:34:06.0000] <nox>
annevk: All is right with the world then. :)

[05:34:24.0000] <annevk>
Good :-)

[05:34:31.0000] <nox>
annevk: I'm not sure we want a context object though, judging from how it's currently written,

[05:34:42.0000] <annevk>
Just waiting for a +1 from bz at this point

[05:34:44.0000] <nox>
I was under the impression that DOM allows you to have some global insertion steps,

[05:34:48.0000] <annevk>
nox: yeah, new parameter is probably better

[05:35:09.0000] <nox>
like something that describes insertion steps whichever the combination of inserted node and parent.

[05:36:07.0000] <annevk>
nox: since in the custom element story these callbacks are per element in the registry and not necessarily associated with instances

[05:36:22.0000] <nox>
annevk: So no context object right?

[05:37:03.0000] <annevk>
nox: I would imagine we pass "currentNode" and "newNode" or some such; I don't think parent makes much sense, since that's newNode.parent

[05:37:22.0000] <annevk>
nox: but I guess I should study what existing libraries do

[05:37:45.0000] <nox>
annevk: I'm not sure we would ever need newNode, and it would keep the symmetry with removing steps.

[05:37:56.0000] <nox>
That's why I suggested a parent, but either way it's fine with me.

[05:38:24.0000] <annevk>
I see

[05:38:28.0000] <nox>
annevk: Given you are cleaning this, might as well clean the order of mutation observers as I mentioned in #60. :P

[05:38:51.0000] <nox>
Oh wait, didn't see your reply on this commit.

[05:38:53.0000] <annevk>
nox: you sure we don't need oldPreviousSibling?

[05:39:06.0000] <nox>
annevk: Not sure, but I will explain why I said that:

[05:39:11.0000] <annevk>
nox: I'm happy to make that change myself

[05:40:25.0000] <nox>
annevk: I was under the impression that the removing steps always let you get oldNextSibling too (given nodes were removed between the two),

[05:40:47.0000] <nox>
but I forgot that nodes might have been added through replaceChild,

[05:41:59.0000] <nox>
anyway, I don't see why you would ever need the previous sibling in the case of insertion, but I guess it wouldn't hurt to be really symmetric.

[05:42:30.0000] <annevk>
I don't think browsers have it for insertion (and there you can just get it). I'm pretty sure it's there for removal though

[05:44:25.0000] <nox>
annevk: I'll try my hand at fixing #60, I'm curious and want to use bikeshed.

[05:45:44.0000] <annevk>
cool

[05:46:42.0000] <annevk>
Such a relieve that fixing insertion/removal is actually this trivial. I was preparing myself for a multiple-days-long-rewrite...

[05:47:09.0000] <kochi>
annevk: I was told from Hayato that the focus navigation order of distributed trees were changed to document order rather than composed tree order to explain <details> <summary>. https://bugs.webkit.org/show_bug.cgi?id=92050

[05:50:12.0000] <annevk>
kochi: okay, but does that mean that shadow tree elements cannot have focus at all?

[05:50:17.0000] <annevk>
kochi: because that seems unlikely

[05:50:27.0000] <annevk>
kochi: and that would need to be explained in some way

[05:51:48.0000] <kochi>
annevk: I don't understand your question... maybe I should have said 'tree-of-trees' order rather than 'document order'?

[05:53:29.0000] <annevk>
kochi: maybe, although tree-of-trees kind of indicates you can focus nodes not rendered anywhere, but maybe that is already true?

[05:54:46.0000] <kochi>
annevk: I think inert nodes are not focusable, and will not be visited via TAB navigation.

[05:55:02.0000] <annevk>
maybe tree-of-trees -> "shadow-including document" at some point

[05:55:15.0000] <annevk>
tree-of-trees is rather weird

[05:56:08.0000] <annevk>
kochi: anyway, either way the current focus model doesn't accommodate shadow trees, agreed?

[05:57:29.0000] <annevk>
kochi: reviewing https://html.spec.whatwg.org/multipage/interaction.html#focus nothing seems to consider them anyway

[05:58:23.0000] <kochi>
annevk: currently in shadow DOM spec, "focus navigation" and "active element" is patched against HTML spec, what do you think is missing still?

[05:59:06.0000] <annevk>
kochi: how does http://w3c.github.io/webcomponents/spec/shadow/#focus-navigation patch HTML?

[06:01:43.0000] <kochi>
annevk: so you want the shadow DOM spec to be actually patcheable to HTML spec?  say, patch to HTML spec "6.4.5 Sequential focus navigation"?

[06:02:59.0000] <annevk>
kochi: yes

[06:03:33.0000] <annevk>
kochi: the goal here is that ShadowRoot et al become just as normal as Text

[06:03:54.0000] <annevk>
kochi: this requires a massive amount of changes since introducing a new kind of node is expensive

[06:04:13.0000] <annevk>
kochi: but if we want to write tests and build new things on top, this is what we have to do

[06:06:34.0000] <kochi>
annevk: hmm, let me understand the goal more.  currently ShadowRoot is a DocumentFragment, and "Text" is a text node, right?

[06:07:17.0000] <annevk>
kochi: yup

[06:08:22.0000] <annevk>
I can phrase it differently perhaps. We have a bunch of specifications and algorithms that assume there is no Shadow DOM. Now there is Shadow DOM. We need to update the bunch of specifications and algorithms to take that into account.

[06:09:16.0000] <kochi>
annevk: ah yeah, the "in a document" thing that Hayato has been working on is a part of it.

[06:09:40.0000] <annevk>
Yeah, Hixie proposed a set of changes for that one too I believe

[06:10:25.0000] <annevk>
Another thing is firing "scoped events" vs firing "unscoped events"

[06:12:26.0000] <kochi>
annevk: so then preparing a rewrite of some sections of HTML spec (esp. 6.4.5 Sequential focus navigation et al.) to take shadow DOM into account to see how the "diff" from the current version is the step that I can take?

[06:13:21.0000] <kochi>
to see how the "diff" from the current version look like

[06:13:21.0000] <annevk>
kochi: yeah, first explain how Shadow DOM focus works in general

[06:13:31.0000] <annevk>
kochi: then introduce a new feature on top

[06:14:03.0000] <kochi>
annevk: okay, let me try.

[06:15:01.0000] <kochi>
I'm not sure how difficult it is, as focus in the HTML spec is already a beast :)

[06:16:14.0000] <annevk>
That is kind of why I would like to see HTML + Shadow DOM focus explained before we add a new feature on top

[06:18:31.0000] <kochi>
annevk: now I think I understand "ShadowRoot et al become just as normal as Text" a little bit more  :)

[06:19:28.0000] <kochi>
it's hard to become a first-class citizen.

[06:20:10.0000] <kochi>
annevk: thanks for your help!

[06:20:21.0000] <annevk>
kochi: thanks for taking it on :-)

[06:25:58.0000] <annevk>
MikeSmith: https://twitter.com/kubosho_/status/625978108189880320

[06:58:32.0000] <johnme>
https://heycam.github.io/webidl/#dfn-create-frozen-array seems to only provide shallow immutability - if it contains e.g. dictionaries, their contents can be mutated freely. Is that a bug? Should it freeze recursively?

[07:01:25.0000] <annevk>
johnme: not sure, Domenic or heycam|away or bz (not in this channel) might be able to help

[07:01:47.0000] <annevk>
johnme: prolly easiest way for a quick response is to file a bug

[07:02:11.0000] <johnme>
annevk: thanks, I'll do that

[07:02:41.0000] <annevk>
johnme: note also that frozen only ever freezes properties, this is really a bit of a hack

[07:03:58.0000] <johnme>
it seems the goal of FrozenArray was to be able to expose objects in an immutable manner, e.g. so that the same object can be returned each time

[07:04:18.0000] <johnme>
so it seems it would make more sense if the immutability was recursive

[07:06:11.0000] <annevk>
johnme: it doesn't make the objects immutable though, so it's unclear whether this trick works for other kind of objects

[07:06:37.0000] <nox>
Given objects aren't immutable in a FrozenArray, why would dictionaries?

[07:07:09.0000] <johnme>
is it too late to change the spec so that objects in a FrozenArray are immutable?

[07:07:37.0000] <annevk>
It's not clear how you'd spec it other than restricting what kind of objects you can put in there

[07:08:06.0000] <annevk>
Or only allowing primitives...

[07:10:00.0000] <johnme>
annevk: I guess I was hoping objects in a FrozenArray would themselves be frozen (have non-writable properties), though that begs the question of whether to freeze objects that can be accessed from the object's properties/methods

[07:10:20.0000] <johnme>
annevk: and if so, how many levels deep this should apply

[07:10:24.0000] <nox>
johnme: Non-writable properties doesn't make them immutable, does it?

[07:10:56.0000] <annevk>
johnme: e.g. if you have a Headers object there, you'd still be able to invoke headersInstance.set(...) and such

[07:11:05.0000] <nox>
To me the change to FrozenArray just meant that you couldn't alter the array shape, not anything else.

[07:11:40.0000] <annevk>
johnme: freeze() is really for some security research from Mark Miller

[07:11:40.0000] <nox>
You don't remove stuff from it, you don't add more things into it, but the things inside you do whatever you want with them.

[07:11:52.0000] <annevk>
johnme: it was used here to make the array immutable, with the hope of later using an actual immutable array

[07:13:15.0000] <johnme>
my use case is adding a sequence of NotificationAction dictionaries to NotificationOptions, that I'd then like to expose on Notification as a FrozenArray<NotificationAction>

[07:13:53.0000] <johnme>
But I guess I'll have to split it into a NotificationActionInit dictionary and a NotificationAction interface with readonly attributes

[07:14:02.0000] <annevk>
johnme: filing a bug on IDL seems like the easiest first step

[07:14:12.0000] <johnme>
ok :)

[07:14:39.0000] <annevk>
johnme: but yeah, I thought Chrome/Blink folks also had some reluctance with returning plain objects, but maybe that changed

[07:21:12.0000] <jochen__>
annevk: is there an example idl for an reflected attribtue that is restrict to valid values only?

[07:21:39.0000] <annevk>
jochen__: usually that's just readonly attribute DOMString attrName;

[07:22:21.0000] <annevk>
jochen__: with invocation of that prose turning it into enum behavior

[07:25:26.0000] <annevk>
jochen__: https://html.spec.whatwg.org/multipage/forms.html#attr-keygen-keytype and https://html.spec.whatwg.org/multipage/forms.html#dom-keygen-keytype for a somewhat simple example

[07:32:21.0000] <jochen__>
thx

[07:33:29.0000] <jochen__>
annevk: for the referrer policy thing, we'd mark the attribute as reflected as well, right?

[07:33:51.0000] <annevk>
jochen__: yeah

[07:34:35.0000] <annevk>
jochen__: the only difference would be that it's the referrerPolicy IDL attribute reflecting the referrerpolicy content attribute (different names)

[07:35:44.0000] <jochen__>
mhm

[07:35:50.0000] <jochen__>
that sounds like something you'd put in prose, no?

[07:36:17.0000] <annevk>
jochen__: https://html.spec.whatwg.org/multipage/forms.html#dom-fs-formenctype

[07:36:20.0000] <annevk>
jochen__: yeah

[07:37:44.0000] <MikeSmith>
annevk: that tweet, the guy just seems to be describing the search syntax he uses when he wants to find out information about an html element

[07:38:02.0000] <annevk>
MikeSmith: yeah, figured, seems kind involved

[07:38:07.0000] <annevk>
kinda*

[07:38:17.0000] <MikeSmith>
yeah

[08:33:04.0000] <wanderview>
https://twitter.com/codepo8/status/626038604964364289

[08:33:16.0000] <wanderview>
having a hard time seeing that post as anything but a troll

[08:33:56.0000] <gsnedders>
meh, it's typical ppk

[08:34:13.0000] <Ms2ger>
So you're in agreement

[08:34:58.0000] <wanderview>
sadly it seems to be working if the twitter threads starting up is any indication

[08:35:02.0000] <wanderview>
I guess I should stop looking at them

[08:36:13.0000] <gsnedders>
yes, there probably should be /more/ focus on fixing bugs in existing features… but that doesn't mean stopping development of stuff going forward

[08:37:26.0000] <annevk>
Domenic: if I want to check that something is in the range 0 to N and is not 5, should I use RangeError for both checks?

[08:40:18.0000] <jgraham>
wanderview: It's all irrelevant. One person saying "let's stop making more features" isn't enough to counteract the huge pressure to keep adding new features

[08:40:48.0000] <wanderview>
jgraham: yep... I'm suffering from "someone is wrong on the internet!" syndrome

[08:40:53.0000] <annevk>
Also, black-and-white positions rarely move the needle

[08:41:05.0000] <jgraham>
and his argument isn't even internally consistent; he cites "offline" as a "experience" thing when it's actually a "feature" thing at this stage

[08:41:36.0000] <Ms2ger>
Well, at least you haven't spent this time implementing new features

[08:41:41.0000] <jgraham>
Plus, I remember in 2007 people arguing that browsers should agree a common timeline on features that they would all polish before moving on

[08:41:57.0000] <jgraham>
I expect this will work as well now as it did then

[08:42:12.0000] <jgraham>
Except ppk will get a few more hits on his site

[08:42:20.0000] <Ms2ger>
I remember that Google was going to drop h264

[08:42:30.0000] <annevk>
Domenic: I'm going to assume I should use a RangeError

[08:42:33.0000] <jgraham>
heh

[08:43:25.0000] <annevk>
I remember that Ms2ger was going to spec DOM Parsing & Serialization

[08:43:54.0000] <Ms2ger>
Lol

[08:45:40.0000] <gsnedders>
yeah, still think he should

[08:47:37.0000] <jgraham>
I imagine the promise looked like google.drop_h264().then(()=>Ms2ger.write_parsing_and_serialization())

[08:48:17.0000] <gsnedders>
But we didn't support ES6 yet then so we just got a SyntaxError

[08:48:17.0000] <annevk>
Kind of confusing for an instance to start with a capital

[08:48:44.0000] <Ms2ger>
More like google.addEventListener("drop_h264", function() { Ms2ger.write_parsing_and_serialization() }), clearly :)

[08:49:09.0000] <wanderview>
I think the "multiple browsers have to implement to be a real standard" keeps things from moving forward too fast... real threat is if one browser has so much market share they can force others to implement things at a reckless pace

[08:49:33.0000] <jgraham>
annevk: Take that up with Ms2ger

[08:51:28.0000] <gsnedders>
wanderview: also different people have different views of reckless… is a few failing I-think-edge-cases-but-nobody-has-started-using-it-yet tests reason to withold shipping? is one or two more likely tests failing reason to, etc?

[08:52:06.0000] <wanderview>
yea... which is why the conditions for "at least 2 agree" consensus state is nice for throttling things

[08:54:28.0000] <smaug____>
we've had plenty of examples of shipping "recklessly"

[08:54:37.0000] <gsnedders>
definitely

[08:55:21.0000] <Domenic>
annevk: sounds good yes

[08:55:22.0000] <botie>
Domenic, at 2015-07-27 04:50 UTC, MikeSmith said: botie now understands "tell"

[10:01:21.0000] <annevk>
mathiasbynens: you want to study https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-open

[10:01:34.0000] <annevk>
mathiasbynens: in particular look at the crazy that is step 15

[10:01:58.0000] <annevk>
mathiasbynens: if you want to answer that Twitter conversation yourself

[10:21:40.0000] <wanderview>
nice: https://twitter.com/w3tmemes/status/626078922980110336

[10:29:55.0000] <mathiasbynens>
annevk: woah. so both Chromium and WebKit are violating the spec here?

[10:30:05.0000] <Ms2ger>
Sure

[10:30:09.0000] <annevk>
mathiasbynens: not sure, they might do it slightly differently

[10:30:20.0000] <annevk>
mathiasbynens: replacing globals is rather involved...

[10:30:37.0000] <annevk>
mathiasbynens: would be interesting to figure out what everyone is really doing

[10:30:55.0000] <mathiasbynens>
i based ^ on the following quick test: data:text/html,<script>a=42</script>

[10:31:04.0000] <mathiasbynens>
and then using DevTools to `document.write(a)`

[10:31:20.0000] <mathiasbynens>
Fx is the odd one out

[10:32:34.0000] <annevk>
Well, I think both WebKit/Blink are doing some work on their Window object bindings, so you might just be observing that

[10:33:04.0000] <annevk>
Could also be something else, hard to say without more tests

[10:39:02.0000] <smaug____>
mathiasbynens: IIRC Gecko and Trident (and Presto) have followed the spec and Webkit (and then also blink) was against the spec

[10:46:20.0000] <beverloo>
annevk, does Firefox support SVGs?

[10:46:26.0000] <beverloo>
(In notification images)

[10:46:40.0000] <annevk>
beverloo: I'm not sure

[10:46:52.0000] <annevk>
beverloo: we support them for favicon finally

[10:47:23.0000] <beverloo>
annevk, interesting, I don't think we support that either

[10:48:01.0000] <annevk>
beverloo: yeah, WHATWG specifications look boring in Chrome

[10:48:14.0000] <annevk>
beverloo: except for HTML, probably because Hixie doesn't insist (yet)

[10:48:33.0000] <annevk>
beverloo: note that usage of SVG there predates Firefox supporting it

[10:49:01.0000] <beverloo>
annevk, sure. we do get a lot of feedback about wanting to generate icons on the fly in a Service Worker, SVG might be a solution for that

[10:49:38.0000] <annevk>
I suspect you'll get "WorkerCanvas" way before "WorkerDOM", but who knows

[10:49:51.0000] <beverloo>
yeah, that'd be great

[10:52:13.0000] <annevk>
beverloo: thanks for helping out with the review btw

[10:54:31.0000] <beverloo>
annevk, John sits right next to me, making it easy to chat :)

[11:04:22.0000] <beverloo>
annevk, svg in favicons is WontFix for IE: https://connect.microsoft.com/IE/feedback/details/782416/svg-favicon-support

[11:04:54.0000] <beverloo>
annevk, the Chrome bug is https://crbug.com/294179, WebKit bug http://wkbug.com/136059

[11:05:15.0000] <beverloo>
annevk, supporting this in favicons is *very* similar for us to supporting it for notification images

[11:07:54.0000] <Domenic>
https://wpdev.uservoice.com/forums/257854-internet-explorer-platform/suggestions/6509196-svg-favicons seems like the new place to be

[11:10:23.0000] <beverloo>
Domenic, cheers! I updated our bug with the latest status

[13:14:10.0000] <annevk>
beverloo: meh, IE wontfixed "XHR2" too

[13:19:11.0000] <Domenic>
hehehe

[15:15:31.0000] <jyasskin_w>
Anyone have thoughts on portably testing exception messages? https://lists.w3.org/Archives/Public/public-test-infra/2015JulSep/0002.html

[15:45:04.0000] <MikeSmith>
jyasskin_w: Ms2ger does

[15:45:50.0000] <jyasskin_w>
Ms2ger: Is my proposal on that thread right? Is there a better way?

[15:45:54.0000] <MikeSmith>
and jgraham, as you know

[15:45:59.0000] <jyasskin_w>
Yep.

[15:46:01.0000] <jyasskin_w>
thx

[15:46:38.0000] <Ms2ger>
I'd rather spec the messages

[15:50:23.0000] <jyasskin_w>
Ms2ger: Interesting, but I'm not sure we can. Different platforms have different information available, and I'd like them to be free to help their developers as much as they can.

[15:51:46.0000] <jyasskin_w>
e.g. platforms may or may not expose the exact GATT error message. It'd be nice to let them show it if they have it, but conform if they don't.

[15:54:34.0000] <jyasskin_w>
slightlyoff says Chrome has a principled objection to specifying messages.

[15:55:53.0000] <smaug____>
if you don't spec something properly, web pages end up relying on the behavior of the browser the developer happens to use. /me agrees with Ms2ger

[15:56:04.0000] <slightlyoff>
specifically messages shown to end users

[15:56:21.0000] <jgraham>
These are API-accessible messages

[15:56:25.0000] <Ms2ger>
Well, then I have a principled objection against testing them

[15:56:30.0000] <slightlyoff>
we are likely to change them over time and won't spec UI

[15:56:52.0000] <slightlyoff>
oh... api accessible....hrm

[15:57:00.0000] <jyasskin_w>
We do have a way to send a different message to the user vs developer, but most of the messages are the .message field.

[15:57:02.0000] <jgraham>
But yeah, I don't think that you should simultaneously say they can't be interoperable and must be tested

[15:57:06.0000] <slightlyoff>
howso?

[15:57:17.0000] <jyasskin_w>
We must test UI, but UI isn't interoperable.

[15:57:32.0000] <slightlyoff>
(and that's OK)

[15:57:36.0000] <jgraham>
Right, but we don't test UI in web-platform-tests

[15:58:04.0000] <jyasskin_w>
And these messages are primarily UI. They do have to be API-accessible so they can be sent back to servers with onerror, but they're for developer consumption, not for testing. If there's a reason for folks to switch on them, that should be reflected in .name, not .message.

[15:58:53.0000] <jyasskin_w>
We're not going to write the web bluetooth tests twice, and we're going to test UI somewhere, so if we can't include the UI test in web-platform-tests, then the Web Bluetooth tests won't be upstreamed.

[15:59:08.0000] <jyasskin_w>
That would be sad.

[15:59:25.0000] <Ms2ger>
Your position makes no sense to me

[15:59:44.0000] <Domenic>
Sebmaster: annevk: web-platform-tests does not test the parsed href?

[15:59:47.0000] <Ms2ger>
Why bother testing if they're not supposed to be relied upon?

[16:00:11.0000] <jyasskin_w>
Ms2ger: We want the developer-facing UI to keep working.

[16:00:17.0000] <jyasskin_w>
Anything that's not tested won't keep working.

[16:00:30.0000] <Domenic>
jeeez it implicitly assembles the href using a different algorithm than the URL spec does !?!

[16:01:04.0000] <Sebmaster>
Domenic: test here: https://github.com/w3c/web-platform-tests/blob/master/url/a-element.html#L47

[16:01:11.0000] <Sebmaster>
but yeah, it assembles somehow :D

[16:01:51.0000] <Domenic>
Sebmaster: https://github.com/w3c/web-platform-tests/blob/master/url/urltestparser.js#L18-L26

[16:01:54.0000] <Domenic>
this is bad

[16:02:03.0000] <Domenic>
isn't the whole file bug about serialization not inserting the //s in the current spec?

[16:02:44.0000] <Sebmaster>
nah not serialization

[16:02:47.0000] <Domenic>
hmm no your patch is in parsing

[16:02:50.0000] <Sebmaster>
parsing i think

[16:02:53.0000] <Domenic>
hmm then i need to go find the failing test case again

[16:03:06.0000] <Sebmaster>
but i guess it'd rather fit into serialization

[16:04:20.0000] <jgraham>
jyasskin_w: FWIW you can't publish a spec at W3C in an actual WG without a testsuite

[16:04:35.0000] <jgraham>
So it seems likely you'll have to do that work at some point

[16:04:37.0000] <slightlyoff>
jgraham: there was of course no plan to

[16:04:38.0000] <Domenic>
Sebmaster: right so the failing test is parsing "/path/to/docroot/index.html" against "file:/path/to/docroot/index.html"

[16:05:01.0000] <Domenic>
Sebmaster: in whatwg-url that results in a href of file:/path/to/docroot/index.html

[16:05:10.0000] <slightlyoff>
jgraham: there's a smaller issue here; which is what we should do about developer-facing strings

[16:05:17.0000] <Domenic>
Sebmaster: whereas it should result in file:///path/to/docroot/index.html

[16:05:21.0000] <slightlyoff>
jgraham: which I don't have the same objection to as end-user-facing UI

[16:05:28.0000] <jyasskin_w>
slightlyoff: Ah, I misunderstood you then.

[16:05:37.0000] <slightlyoff>
no, I misunderstood

[16:05:39.0000] <slightlyoff>
my fault

[16:05:41.0000] <Domenic>
Sebmaster: seems like a serialization patch would be better (but there are no tests)

[16:05:48.0000] <Sebmaster>
Domenic: since the path in that case would just be /path/to/docroot/index.html, this should probably go into serialization

[16:05:49.0000] <Sebmaster>
yeah

[16:05:58.0000] <Domenic>
nooooo tesssssstsss -_-

[16:06:36.0000] <jgraham>
hallvors: Got any good examples of error message strings causing compat problems?

[16:07:07.0000] <slightlyoff>
I'd also like to understand the value of i18n of developer-facing strings

[16:07:18.0000] <slightlyoff>
I'm not sure it's something we do much of today

[16:07:23.0000] <slightlyoff>
but I'm ignorant there

[16:07:42.0000] <jgraham>
Yeah, I don't know either.

[16:07:51.0000] <Domenic>
sicking and I always had the idea to add some machine-readable unique standardized string

[16:08:18.0000] <Domenic>
error.cause === "could_not_parse_base_url"

[16:08:30.0000] <Domenic>
corresponding to 2.2 in https://url.spec.whatwg.org/#constructors

[16:08:34.0000] <Domenic>
or a guid

[16:09:31.0000] <jyasskin_w>
I don't think we can implement stable message strings in Chrome on multiple platforms without dropping lots of information. e.g. ChromeOS exposes different error conditions than MacOS. Neither documents their error conditions, either.

[16:10:24.0000] <jgraham>
Then it seems like you are going to end up changing your expectations here for every OS upgrade

[16:11:30.0000] <jyasskin_w>
Absolutely. That's why my first patch supported regular expressions, so we can keep the actual test somewhat stable over time. But skipping the message tests isn't going to stop developers from depending on them, either.

[16:14:40.0000] <jgraham>
Anyway, if you want to supply a patch that allows you to attach arbitary information to a particular test object and transfer it in the result; something like test.add_data(name, data) I guess I would accept that. You could output that data in expectation files in Chromium. But I think you're letting yourself in for a world of pain if later someone does the same thing for something that isn't stable in Chrome and can't be compared using expectation 

[16:17:53.0000] <jyasskin_w>
jgraham: Thanks. I should go back to blink-dev to see if folks there have more thoughts. I'm not certain this is the right interface either, but I do think we need _something_.

[16:21:58.0000] <jgraham>
I think fundamentally if you want to do this you need your test harness to support test-specific logic that can be used to whitelist the cases where you want to compare the proprietary bits

[16:22:36.0000] <jgraham>
If the blink test harness just does byte-by-byte comparisons with expectation files, that's not good enough

[16:25:56.0000] <jyasskin_w>
Right, it'll break too often, including if we just have different-but-stable messages on two platforms. On the other hand, test.add_data(name, data) does give us the flexibility to write any assertions we need in the harness.


2015-07-29
[17:19:14.0000] <MikeSmith>
WTF https://github.com/Semantic-Org/Semantic-UI/issues/1526

[17:19:30.0000] <MikeSmith>
<div class="sixteen wide mobile eight wide tablet four wide computer column">

[17:19:45.0000] <Domenic>
that's the new craze MikeSmith.

[17:21:35.0000] <MikeSmith>
Domenic: they're in for some good times with that stuff

[17:22:00.0000] <MikeSmith>
"'word order significant' class names"

[17:22:16.0000] <MikeSmith>
"For me the use of significant class order is an ideological stand."

[17:24:25.0000] <MikeSmith>
「Otherwise as programmers how could we possibly define "right"ness, without acknowledging the importance of contextual significance, like "right aligned" or "right floated".」

[17:24:33.0000] <MikeSmith>
semiotics

[17:24:56.0000] <MikeSmith>
Cours de linguistique generale

[17:28:35.0000] <MikeSmith>
https://github.com/AmpersandJS/amp/issues/52#issuecomment-69646723

[17:28:47.0000] <MikeSmith>
「I think an argument that "the standard says to do X or Y" acts as an appeal to authority and not necessarily an argument for validity. Just like an argument over the morality of the death penalty would be stopped short if we just relied on a de jure argument like, "Well its current (legal/illegal) in my country". 」

[17:29:52.0000] <MikeSmith>
annevk: seems like a good candidate to recruit as a spec editor

[20:24:50.0000] <psynone>
algum brasilero aqui?

[22:24:56.0000] <annevk>
MikeSmith: to be fair, that is kind of the way we talk about REC

[22:25:14.0000] <annevk>
(maybe I'm stretching it a bit)

[22:28:11.0000] <MikeSmith>
annevk: yeah I get your point though maybe you are stretching it a bit

[22:28:24.0000] <MikeSmith>
personally I like stretching things a bit

[22:28:53.0000] <MikeSmith>
or even beating them into the ground

[22:29:09.0000] <MikeSmith>
sometimes great insights can emerge from it

[22:29:25.0000] <MikeSmith>
but if not, at least we get the lulz

[22:33:54.0000] <annevk>
At least we're not filling our mornings with ISO discussions like TC39 did apparently

[22:34:27.0000] <MikeSmith>
well I understand the strategy

[22:35:01.0000] <MikeSmith>
in that, the rest of the meeting can't get any worse than that

[22:35:33.0000] <MikeSmith>
who's the actual chair of TC39? Does it have a chair?

[22:35:50.0000] <MikeSmith>
as in, who runs the meeting and cuts people off when needed, etc.

[22:39:01.0000] <annevk>
MikeSmith: John Neumann is the official chair

[22:39:18.0000] <annevk>
MikeSmith: Brendan Eich de facto in my fairly limited experience

[22:40:18.0000] <MikeSmith>
ok

[22:40:24.0000] <annevk>
MikeSmith: but each meeting has a bit about Ecma and standards formality that mostly died in the nineties, but not in Ecma/TC39

[22:40:58.0000] <MikeSmith>
that part seriously sounds like fun

[22:41:06.0000] <MikeSmith>
we don't have enough of that

[22:41:43.0000] <MikeSmith>
standards meetings should be a bit more like going to Catholic mass

[22:42:34.0000] <MikeSmith>
like there's the part in the mass where you have to turn around and shake hands with the people sitting behind you, and say, "Peace be with you." And they say, "And also with you."

[22:43:03.0000] <MikeSmith>
and the singing too

[22:43:24.0000] <MikeSmith>
DanC tried to introduce more singing

[22:43:35.0000] <MikeSmith>
to meetings

[22:44:03.0000] <MikeSmith>
and sorta hippie-ish guitar-playing

[22:44:08.0000] <MikeSmith>
I liked that

[00:59:38.0000] <annevk>
igrigorik: https://github.com/whatwg/fetch/issues/93#issuecomment-125770410 is nice, though worker is a ResourceType

[00:59:52.0000] <annevk>
igrigorik: and we need to distinguish the types of workers I think

[01:00:46.0000] <annevk>
igrigorik: Initiator makes sense to explain "form", but I'm not sure we need to to beyond that for now. "script" there seems dubious, is invoking new Image(src) script? Invoking <img>.setAttribute()?

[02:14:10.0000] <nox>
annevk: Pushed code to this issue #60.

[02:14:13.0000] <nox>
https://github.com/whatwg/dom/pull/60

[02:43:13.0000] <annevk>
nox: thank you. You already checked for no observable differences, right?

[02:45:25.0000] <nox>
annevk: AFAIK there are none but you should check the transient observers step in replace.

[02:47:07.0000] <annevk>
nox: in remove?

[02:48:17.0000] <nox>
annevk: Oh yes but I'm commuting. The step about ancestors having subtree observers.

[02:49:22.0000] <nox>
Now the order of operations should be the same when appending or replacing all elements of a node without children.

[03:30:59.0000] <annevk>
smaug____: I'm trying to figure out https://github.com/whatwg/dom/issues/34 still

[03:31:53.0000] <annevk>
smaug____: per https://dom.spec.whatwg.org/#concept-node-remove-ext currently we only run that once

[03:32:10.0000] <smaug____>
so you go through the tree once, in tree order, and for each operation which might need scripts to run, post a nanotask to call the script?

[03:32:16.0000] <annevk>
smaug____: the change would be to run it for the inclusive descendants of /node/ during step 8

[03:32:35.0000] <smaug____>
ah, right

[03:32:39.0000] <annevk>
smaug____: however, what should we call the arguments then?

[03:32:48.0000] <annevk>
smaug____: removedNode, oldAncestor, oldPreviousSibling?

[03:32:57.0000] <annevk>
smaug____: I can't find oldPreviousSibling as a thing in Gecko

[03:33:30.0000] <annevk>
smaug____: also, in relation to oldAncestor, oldPreviousSibling is an odd name

[03:34:09.0000] <smaug____>
http://mxr.mozilla.org/mozilla-central/source/dom/base/Element.cpp#1396 is the insertion case, http://mxr.mozilla.org/mozilla-central/source/dom/base/Element.cpp#1663 is the removing case

[03:34:23.0000] <annevk>
(I think another difference is that in Gecko UnbindFromTree is on the instance, not a standalone callback, but I'm not going to change that for now.)

[03:34:47.0000] <annevk>
smaug____: that's only for elements though, not nodes in general

[03:35:03.0000] <annevk>
smaug____: but yeah, that doesn't seem to keep track of oldPreviousSibling

[03:35:14.0000] <smaug____>
well, data nodes have similar bind/unbind

[03:35:28.0000] <smaug____>
annevk: right

[03:35:38.0000] <smaug____>
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsINode.cpp#1679

[03:35:39.0000] <annevk>
smaug____: and it calls it "oldParent", while it might not be the oldParent of the instance it was invoked on...

[03:35:59.0000] <smaug____>
annevk: so we call ContentRemoved before unbind

[03:36:28.0000] <annevk>
What's the difference?

[03:36:42.0000] <smaug____>
which means one can use nsIMutationObserver if one needs that information

[03:36:50.0000] <smaug____>
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIMutationObserver.h#257

[03:37:32.0000] <annevk>
Interesting, so we have several internal callbacks

[03:37:50.0000] <smaug____>
well, nsIMutationObserver is the callback interface

[03:38:11.0000] <smaug____>
Bind/Unbind are the actual methods on nodes to do something

[03:38:16.0000] <smaug____>
I wouldn't call them callbacks

[03:38:52.0000] <smaug____>
(DOM) MutationObserver is implemented internally as an nsIMutationObserver

[03:40:46.0000] <annevk>
I think ideally specifications only use one of them

[03:41:06.0000] <smaug____>
Bind/Unbind set the .parentNode and iterate all the child nodes and so

[03:41:46.0000] <annevk>
And e.g. https://dom.spec.whatwg.org/#nodeiterator needs oldPreviousSibling

[03:42:22.0000] <smaug____>
NodeIterator in Gecko is also nsIMutationObserver http://mxr.mozilla.org/mozilla-central/source/dom/base/NodeIterator.h?force=1#25

[03:43:20.0000] <smaug____>
Bind/Unbind implement a part of the node-insert/removal algorithm from the spec, and nsIMutationObserver is then closer to the callbacks we want to add

[03:43:43.0000] <annevk>
The problem is that mutation observers in Gecko can be synchronous, and the specification doesn't have such a concept

[03:43:52.0000] <smaug____>
right

[03:44:16.0000] <annevk>
I guess we could add that concept and some abstract language of using mutation observers here and there...

[03:45:01.0000] <annevk>
But I think that might be more confusing than always using "insertion steps" and "removing steps" for synchronous operations

[03:45:03.0000] <smaug____>
spec should talk about something else than "mutation observer", to not confuse with MutationObserver

[03:45:29.0000] <smaug____>
hmm, what you mean?

[03:45:36.0000] <annevk>
If the specification "removing steps" did get passed an oldPreviousSibling, is there anything that would be different?

[03:45:36.0000] <smaug____>
with sync ops?

[03:46:15.0000] <annevk>
smaug____: for everything where specifications want to react synchronously to the insertion or removal of some node

[03:46:29.0000] <annevk>
smaug____: e.g. <iframe> or Fullscreen

[03:46:38.0000] <smaug____>
so you mean nano task stuff

[03:46:41.0000] <smaug____>
not sync

[03:46:45.0000] <annevk>
no I don't mean that

[03:47:04.0000] <smaug____>
sync is something which can't run scripts, right?

[03:47:04.0000] <nox>
Are we still on insertion/removing steps?

[03:47:20.0000] <annevk>
smaug____: ideally

[03:47:49.0000] <annevk>
smaug____: simple example is NodeIterator

[03:47:59.0000] <smaug____>
ok, so this is spec level stuff

[03:48:46.0000] <annevk>
smaug____: if we change "removing steps" to be invoked for inclusive descendants, does that a) still work and b) how do we name the arguments sanely

[03:48:49.0000] <annevk>
smaug____: yeah

[03:48:51.0000] <smaug____>
I'm now not sure what we're talking about :) spec level sync stuff, or callbacks to JS

[03:48:59.0000] <annevk>
smaug____: though I suspect the nanotask stuff to come on top

[03:49:15.0000] <annevk>
smaug____: spec level sync stuff for now

[03:49:36.0000] <annevk>
nox: yes

[03:53:49.0000] <smaug____>
so Gecko does http://mxr.mozilla.org/mozilla-central/source/dom/base/nsINode.cpp#1679, so ContentRemoved is called first on the thing removed, and then UnbindFrom tree is called, and it calls itself recursively on child nodes, and for the removed node and each  descendant ParentChainChanged is called separately http://mxr.mozilla.org/mozilla-central/source/dom/base/Element.cpp#1784

[03:55:01.0000] <smaug____>
so when removing, in the spec, would it make sense to have spec level "callback" for node-removed, and then parentChainChanged for each descendants?

[03:55:11.0000] <annevk>
Right, I wonder if the simplistic concept the specification has now, combined with it being invoked for descendants, is sufficient even for the cases where Gecko might use a synchronous mutation observer to implement them.

[03:55:26.0000] <nox>
Aren't you having the same discussion than yesterday?

[03:56:18.0000] <annevk>
nox: similar, but not the same

[04:00:41.0000] <annevk>
smaug____: I'm not sure, would the first be invoked with oldPreviousSibling and the second not? Or some such?

[04:02:43.0000] <smaug____>
annevk: the second would just tell that parent chain has changed

[04:03:05.0000] <smaug____>
since for descendants siblings are still the same

[04:03:16.0000] <beverloo>
annevk, fair :)

[04:04:14.0000] <annevk>
smaug____: I guess that may be sufficient, I'm unfortunately not familiar with all callers :-/

[04:04:28.0000] <annevk>
Well, all places that are hooked into this

[04:05:34.0000] <smaug____>
let me look at some UnbindFromTree implementations in Gecko. Some elements do override the default one and do something and then call the default one

[04:06:14.0000] <smaug____>
effectively to have the parentChainChanged call on them

[04:06:14.0000] <smaug____>
without implementing nsIMutationObserver

[04:06:50.0000] <smaug____>
nsIMutationObserver in Gecko is meant to be used by other elements or nodelists etc. when the change isn't happening on your object

[04:06:53.0000] <annevk>
So you're suggesting node::unbind(oldParent, oldPreviousSibling), node::ancestorUnbind()

[04:08:12.0000] <annevk>
Oh right, actually defining NodeList, now that would be something...

[04:10:13.0000] <smaug____>
sorry, network issues. /me kicks the over-the-forest-under-the-lake phone line

[04:11:39.0000] <smaug____>
annevk: yeah, unbind on the removed element only, and then parentChainChanged for that and for descendants.

[04:11:52.0000] <smaug____>
or just node::ancestorUnbind() for descendants

[04:12:11.0000] <smaug____>
but let me looks some Unbind impls

[04:12:31.0000] <annevk>
I'm going to email some Google folks too

[04:14:08.0000] <smaug____>
so UnbindFromTree overrides tend to check whether there is still parent and if not and elements behavior depends on parent, do something. Or, do something because the element isn't in document anymore

[04:14:29.0000] <smaug____>
so both those could be done based on the parentChainChanged information

[04:15:05.0000] <annevk>
yeah

[04:18:06.0000] <smaug____>
one thing some code seems to use is that when UnbindFromTree is called on element which ancestor was in document, the element itself has still the flag "in-document", and that flag is cleared during UnbindFromTree.

[04:18:23.0000] <Ms2ger>
https://github.com/emilbjorklund/svg-weirdness

[04:19:51.0000] <annevk>
smaug____: I've been wondering, is it actually "in-document" or "in-window-associated-document"?

[04:19:56.0000] <smaug____>
so maybe node::ancestorUnbind() should have a param telling whether the ancestor used to be in-document

[04:20:23.0000] <smaug____>
it is in-document in Gecko

[04:22:13.0000] <smaug____>
if you need to know in-window-associated-document, just check if(node.ownerDocument.defaultView)

[04:23:43.0000] <annevk>
that's why it might make sense to pass the ancestor

[04:23:53.0000] <annevk>
so you can just check it on ancestor

[04:26:08.0000] <smaug____>
why would you do that

[04:26:19.0000] <smaug____>
if you have the information on the node itself

[04:26:37.0000] <smaug____>
oh, one thing, Gecko calls Bind/Unbind on shadow elements too

[04:26:42.0000] <annevk>
"maybe node::ancestorUnbind() should have a param telling whether the ancestor used to be in-document"

[04:27:28.0000] <annevk>
smaug____: composed tree or just going into each attached shadow tree?

[04:31:02.0000] <smaug____>
oh, I see a bug there for multiple shadow roots

[04:31:54.0000] <smaug____>
anyhow, it accesses shadowroot and Bind/Unbind all the child nodes of shadowroot

[04:32:07.0000] <smaug____>
that is implementation detail that shadowroot doesn't need bind/unbind

[05:11:11.0000] <JonathanNeal>
Promise.race is similar to Array#every. Is there something like Promise.any similar to Array#some?

[05:13:06.0000] <beverloo>
Do you mean s/race/all/?

[05:20:12.0000] <jgraham>
It seems like .race should be similar to .some and .all similar to .every

[05:20:22.0000] <jgraham>
Unless the names are very misleading

[05:58:05.0000] <annevk>
mkwst: fyi: https://github.com/whatwg/fetch/issues/93

[05:59:17.0000] <annevk>
smaug____: okay, so it's just going in without caring about whether the nodes are actually composed or not

[06:00:14.0000] <annevk>
smaug____: I guess it goes into shadow trees before first child/next sibling?

[06:03:50.0000] <hallvors>
jgraham: I can't remember seeing a single compat problem caused by error object's message..

[06:35:59.0000] <smaug____>
annevk: in Gecko it goes into shadow tree after non-shadow tree children. Not sure which one should come first.

[06:38:17.0000] <annevk>
Making up words: inclusive shadow-tree-including-descendants in shadow-post-tree order

[06:41:13.0000] <smaug____>
annevk: in Gecko it goes into shadow tree after non-shadow tree children. Not sure which one should come first.

[06:41:47.0000] <annevk>
smaug____: you were online the first time :-)

[06:41:58.0000] <smaug____>
ahaa

[06:42:04.0000] <smaug____>
/me switched network

[06:42:13.0000] <smaug____>
/me reads log

[06:42:30.0000] <annevk>
I didn't say anything intelligent

[08:00:20.0000] <annevk>
smaug____: philipj: for mayCancel, I guess if we disable addEventListener() as well as preventDefault() there might be more of a fighting chance

[08:00:47.0000] <annevk>
smaug____: philipj: though in that case we need to be wary of events dispatching from the same task (or have the optimization take place inbetween or some such, if that even makes sense)

[08:01:25.0000] <smaug____>
disable addEventListener?

[08:05:02.0000] <annevk>
smaug____: otherwise a mayCancel listener can add a non-mayCancel listener during dispatch

[08:05:42.0000] <annevk>
(I hope we end up with a better name than mayCancel.)

[08:05:56.0000] <annevk>
("passive" sounds rather good actually.)

[08:06:01.0000] <smaug____>
would it be horrible to make that throw

[08:06:33.0000] <smaug____>
inside mayCancel == false listener you could add only mayCancel == false listeners

[08:06:41.0000] <smaug____>
hm

[08:06:46.0000] <smaug____>
/me doesn't like that

[08:07:13.0000] <annevk>
I would just make addEventListener throw

[08:07:29.0000] <smaug____>
any addEventListener call?

[08:07:41.0000] <smaug____>
or only for the currently dispatched event type?

[08:07:43.0000] <smaug____>
or what

[08:08:00.0000] <annevk>
Only for the passive callback

[08:08:19.0000] <smaug____>
don't understand

[08:08:22.0000] <annevk>
The UA can then make an optimization if it only sees passive callbacks

[08:08:43.0000] <annevk>
Without having to worry about passive callbacks adding new listeners that violate the passiveness

[08:08:46.0000] <smaug____>
what would throw and when?

[08:09:20.0000] <annevk>
preventDefault() and addEventListener() would throw during passive listener callbacks

[08:10:29.0000] <annevk>
Hmm, somehow post-callback microtasks should also be guarded, otherwise there's an escape

[08:10:38.0000] <smaug____>
addEventListener for any event type?

[08:10:59.0000] <annevk>
smaug____: I guess you could scope it

[08:11:21.0000] <annevk>
smaug____: haven't considered the details

[08:12:08.0000] <annevk>
smaug____: might depend a bit on how many events are typically dispatched together from one task, something we haven't specified :-(

[08:12:26.0000] <smaug____>
indeed

[08:13:38.0000] <annevk>
yay for "passive" meanwhile

[09:44:30.0000] <ccardona-work>
Good morning WHATWGians! o/

[09:47:57.0000] <annevk>
morning ccardona-work

[09:48:27.0000] <ccardona-work>
annevk: Good morning *hat tip* 🎩 👽

[09:49:15.0000] <annevk>
Domenic: humor me, the s/deterministic/consistency/  change would be because we could offer deterministic points in time to invoke the callbacks, but they would simply not be great?

[09:50:02.0000] <annevk>
johnme: beverloo: I wonder, is actions your just-before-going-home project?

[09:50:36.0000] <Domenic>
annevk: yeah, where "not great" is more precisely that when using createElement You have no children or attributes, but otherwise you do.

[09:51:08.0000] <Domenic>
(parsing could be either one; upgrades must have children and attributes)

[09:51:08.0000] <annevk>
I guess I should reword that so this remains a useful point of reference, thanks

[09:51:24.0000] <Domenic>
\o/ thanks

[09:59:23.0000] <johnme>
annevk: sorry, just happened to finish addressing the comments now :)

[10:00:13.0000] <annevk>
johnme: heh, I don't mind at all when you do it

[10:00:22.0000] <annevk>
Domenic: should be fixed now

[10:20:48.0000] <wanderview>
annevk: this is the XHR spec you updated for fetch? https://xhr.spec.whatwg.org/

[10:26:20.0000] <annevk>
wanderview: that's the only XHR spec still getting updates to my knowledge

[10:26:24.0000] <annevk>
(yes)

[10:26:40.0000] <wanderview>
annevk: its the "still getting updates" thats hard for me to infer when searching online

[10:26:58.0000] <annevk>
"Last Updated 14 July 2015"

[10:27:20.0000] <wanderview>
annevk: yea... but when searching for a spec... I don't know if I just didn't see one with a newer date, etc

[10:27:27.0000] <wanderview>
finding "the right spec" kind of sucks

[10:27:31.0000] <wanderview>
for newbies like me

[10:27:44.0000] <annevk>
wanderview: I guess the other thing is that if it has spec.whatwg.org in the name, it's the one you want

[10:28:19.0000] <annevk>
wanderview: if it has TR/ in the name, highly unlikely

[10:28:30.0000] <annevk>
wanderview: anything else, proceed with caution

[10:28:52.0000] <wanderview>
annevk: I'll just use http://www.w3schools.com/xml/xml_http.asp

[10:39:28.0000] <tantek>
is linking to w3schools unironically considered trolling?

[10:42:29.0000] <wanderview>
tantek: I'm pretty sure I was trying to troll annevk

[13:36:07.0000] <JoWie>
should start a whatwgschools

[13:37:19.0000] <zcorpan>
whatschools

[13:43:57.0000] <caitp>
make it happen

[13:49:43.0000] <Domenic>
wanderview: https://github.com/mozilla/servo/wiki/Relevant-spec-links for the right spec is my go-to

[13:50:05.0000] <Domenic>
I guess XHR isn't there explicitly

[13:50:32.0000] <wanderview>
Domenic: thanks

[13:51:46.0000] <wanderview>
also, I would call it w2gschools

[14:00:12.0000] <tantek>
whatschools++

[14:09:43.0000] <Ms2ger>
Domenic, you're welcome ;)

[14:10:07.0000] <Domenic>
:)

[14:22:53.0000] <gsnedders>
wtfschools


2015-07-30
[17:00:24.0000] <JonathanNeal>
jgraham: so I take it no?

[17:01:05.0000] <JonathanNeal>
I’m looking for a method that would return a promise that resolves as soon as one of the promises in the iterable resolves, or that rejects once all of the promises in the iterable rejects, with the value or reason from that promise.

[17:02:16.0000] <JonathanNeal>
Oh good, I’m not the first person to notice this http://www.effectiveui.com/blog/2014/11/11/promise-any-a-missing-use-case/

[17:50:11.0000] <MikeSmith>
/me does http://dev.w3.org/csswg/ -> https://drafts.csswg.org/ on a bunch of links in https://github.com/servo/servo/wiki/Relevant-spec-links

[17:50:22.0000] <MikeSmith>
wanderview: https://platform.html5.org/ attempts to provide links to the right versions of specs

[17:51:22.0000] <MikeSmith>
wanderview: following, e.g., the "Prefer WHATWG specifications over W3C ones" rule and the "Always use the Editor's Draft" rule, etc.

[17:51:32.0000] <MikeSmith>
Domenic: 👆

[17:52:39.0000] <MikeSmith>
in any cases where it doesn't, that's a bug and should get an issue report or PR at https://github.com/whatwg/platform.html5.org

[18:45:03.0000] <JonathanNeal>
Where can I learn the most about the “system” font?

[19:08:27.0000] <TabAtkins>
JonathanNeal: There is no such function (we only had real use-cases for .all() and .race()), but you can make one yourself by flipping the input promises, calling .all() on them, then flipping the result promise.

[19:08:46.0000] <TabAtkins>
Flipping a promise is just throwing the success value and returning the error value.

[19:09:13.0000] <TabAtkins>
p.then(x=>throw x, x=>x)

[19:15:17.0000] <JonathanNeal>
TabAtkins: that’s a fun hack, but wouldn’t actual errors end up throwing an ultimate resolve?

[19:15:39.0000] <TabAtkins>
?

[19:16:31.0000] <JonathanNeal>
If something in a promise throws, is the Promise rejected?

[19:16:46.0000] <TabAtkins>
Yes.

[19:17:12.0000] <JonathanNeal>
So, if something actually errored in the Promise, it wouldn’t know the difference between that error and my flipping of the Promise?

[19:18:03.0000] <TabAtkins>
I'm confused.  I think your mental model is a little bit broken, and so you're asking a weird question?

[19:18:12.0000] <JonathanNeal>
That’s very possible.

[19:18:46.0000] <TabAtkins>
Why are you making a distinction between "throws an error" and "rejects (in some normal way)"?

[19:18:57.0000] <TabAtkins>
Rejection is the promise equivalent of error-throwing, anyway.

[19:19:19.0000] <JonathanNeal>
I thought you were saying I should use Promise.all, but reject when I mean to resolve and resolve when I mean to reject.

[19:19:42.0000] <TabAtkins>
I said flip all the input promises, then use Promise.all, then flip the result promise, and return that.

[19:20:22.0000] <TabAtkins>
The initial flips means the Promise.all() will either accept (if all of the input promises rejected) or reject (if a single input promise accepted).

[19:20:41.0000] <TabAtkins>
Then you flip it again so the promise you end up returning actually accepts or rejects in the expected manner.

[19:20:43.0000] <JonathanNeal>
Right, so the initial Promise works as intended, but it’s result gets flipped before being passed to Promise.all?

[19:21:13.0000] <JonathanNeal>
And then the result of Promise all gets flipped and that’s my Promise.any?

[19:21:57.0000] <TabAtkins>
Yeah.  "Promise.any = function(...inputs) { return promiseFlip(Promise.all(...inputs.map(promiseFlip))); };"

[19:22:36.0000] <TabAtkins>
Where "function promiseFlip(p) { return p.then(function(x){throw x;}, function(x){return x;}); };"

[19:24:14.0000] <JonathanNeal>
My error in thinking was neglecting to consider the inner promiseFlip.

[19:25:00.0000] <JonathanNeal>
That’s a very clever way to do it, but one would still end up abstracting it to something like Promise.any. Would you say your method is better than these forEach’ing over the iterables? Like https://github.com/andyjansson/promise-any/blob/master/index.js

[19:25:48.0000] <TabAtkins>
I suddenly want to do much more functional code: Promise.any = compose(promiseFlip, Promise.all, map(promiseFlip));

[19:26:11.0000] <TabAtkins>
forEach'ing is just a straightforward translation of a Promise.all() impl into .any().

[19:26:41.0000] <TabAtkins>
Which is easier depends on how well you handle more functional stuff, I guess?

[19:26:59.0000] <TabAtkins>
In general I vastly prefer working with promises directly if at all possible, and avoiding promise constructors entirely.

[19:27:58.0000] <TabAtkins>
(I think Domenic prefers that pattern as well.)

[19:29:50.0000] <JonathanNeal>
I follow, but I did not learn enough about functional programming to really grasp it.

[19:30:26.0000] <TabAtkins>
http://drboolean.gitbooks.io/mostly-adequate-guide/

[19:31:00.0000] <JonathanNeal>
Is compose a real thing? Or an abstraction? Or like f => g => (...xs) => f(g.apply(this, xs)) ?

[19:31:40.0000] <TabAtkins>
Well, like, it's a function you can write yourself.

[19:32:57.0000] <TabAtkins>
function compose(...funcs) { return function(...args) { var ret = funcs[0](...args); for(var i = 1; i < funcs.length; i++) { ret = funcs[i](ret); } return ret; };};

[19:33:22.0000] <TabAtkins>
(You don't mess around with `this` when writing functional style code, `this` is for OO.)

[19:35:37.0000] <TabAtkins>
Sorry, have to run funcs in reverse, duh.

[19:36:51.0000] <JonathanNeal>
And it would not be classy to var ret = funcs.splice(0)[0](...args); ?

[19:36:57.0000] <JonathanNeal>
So that one could for (func of funcs) ret = func(ret);

[19:37:27.0000] <TabAtkins>
I mean, whatevs, you're writing a for loop, do whatever you want.

[19:37:37.0000] <TabAtkins>
I never remember how splice() works, so I just did it manually.

[19:39:43.0000] <JonathanNeal>
And I can’t do like compose(ret, …funcs) {} ?

[19:40:27.0000] <TabAtkins>
Are you calling (in which case, why the {}) or defining (in which case, where the "function")?

[19:40:30.0000] <JonathanNeal>
You know, at some point you shouldn’t forgive me knowing neither functional programming or proper ES6. Thank you for being so patient.

[19:41:33.0000] <JonathanNeal>
I’m just learning by dissecting your compose method based on what you shared about Promise.any.

[19:42:05.0000] <TabAtkins>
Yeah, but when you says `compose(ret, ...funcs) {}`, were you trying to reference *calling* the compose() function, or *defining* it?

[19:42:30.0000] <JonathanNeal>
defining it

[19:42:33.0000] <TabAtkins>
Ok.

[19:43:05.0000] <TabAtkins>
Yeah, you can put arguments before the rest param.  But that won't help here, because you have to reverse the list of funcs first (you run the last one with args, then pass its result to the next to last, etc). ^_^

[19:43:28.0000] <TabAtkins>
In my dfn, pretend the first line of compose() was "funcs.reverse();", followed by the return statement as I specified it.

[19:43:56.0000] <JonathanNeal>
I’m doing more than pretend. I’m writing it in Sublime. Studying it. Then responding :)

[19:45:47.0000] <JonathanNeal>
And double checking that .reverse does in fact modify the instance rather than just returning the reordered array.

[19:45:55.0000] <TabAtkins>
Yes, it does both.

[19:45:55.0000] <JonathanNeal>
Because I forgot.

[19:46:02.0000] <TabAtkins>
(Which is annoying.)

[19:46:05.0000] <TabAtkins>
(Most of the time.)

[19:46:51.0000] <TabAtkins>
My Promise.any() up there won't actually work, btw, because Promise.all() expects to receive multiple args, not an array.  Gotta use some helper function to make that work.

[19:47:44.0000] <TabAtkins>
Like function argsToArray(func) { return function(arrayOfArgs) { return func(...arrayOfArgs); };};

[19:48:42.0000] <TabAtkins>
And function arrayToArgs(func) { return function(...args) { return func(args); };};

[19:49:27.0000] <TabAtkins>
So then Promise.any = arrayToArgs(compose(promiseFlip, argsToArray(Promise.all), map(promiseFlip)));

[19:50:02.0000] <TabAtkins>
Oh, and function map(func) { return function(obj) { return obj.map(func); };};

[19:50:24.0000] <JonathanNeal>
I follow, though the number of methods required to write that one beautiful line seemed a bit much.

[19:50:27.0000] <TabAtkins>
I highly recommend reading the DrBoolean's guide I linked above, it's a super newb-friendly intro to FP in JS.

[19:51:09.0000] <TabAtkins>
Well, most of those are helpers that would be prewritten, and the array<->arg converters wouldn't be necessary if the functions accepted arrays all the time.  FP doesn't like variadic functions very much.

[19:51:10.0000] <JonathanNeal>
I have read two “page”. I don’t know if I’m a newb or not, but it’s definitely me-friendly.

[19:51:15.0000] <JonathanNeal>
pages

[19:52:57.0000] <TabAtkins>
(Back in Lisp, where you can name functions nice ASCII things, they were named <> and ><, to represent whether they "spread" the function (changing it from accepting a single array to accepting multiple args) or "squished" it (vice versa).

[19:53:16.0000] <TabAtkins>
So (>< Promise.any) was easier to read. ^_^

[19:55:43.0000] <hgl>
sorry to chime in with a different topic, but i have some thoughts on cancelable promises, is it appropriate to discuss here?

[19:55:56.0000] <TabAtkins>
hgl: Yeah. Ping Domenic for it.

[19:56:26.0000] <hgl>
great, here are my thoughts on cancelable promises https://gist.github.com/hgl/fa6432904ddcf29ecafe

[19:56:51.0000] <hgl>
i'm going to cc annevk too

[20:04:55.0000] <JonathanNeal>
Haha reading chapter 3 and it’s telling me about the impurity of splice. Thank you again, Tab.

[20:12:17.0000] <TabAtkins>
hehehe

[20:40:12.0000] <JonathanNeal>
Chapter 5, midway, is a good place or me to stop and digest. :)

[22:04:56.0000] <JonathanNeal>
This might seem really stupid to people, but I put together a collection of @font-face rules that might form the “system” font https://gist.github.com/jonathantneal/32fdf75b26fd12c7c7db

[22:36:05.0000] <JonathanNeal>
Formalized it a little https://github.com/jonathantneal/system-font-face

[00:33:16.0000] <terinjokes>
JonathanNeal: in my version of similar, I also have Roboto, Liberation Sans and Arimo

[00:34:23.0000] <terinjokes>
I don't have San Francisco, and it seems I've also included the office font of "Calibri" for some reason

[00:53:02.0000] <howdoi>
I found a bug in npmjs.com, where can I find the code so that I can send a fix? `newww` repo?

[00:53:34.0000] <howdoi>
never mind...

[00:57:50.0000] <howdoi>
It's more related to doc, in https://github.com/npm/docs/tree/master/content I find everything except the md related to  https://docs.npmjs.com/files/package.json

[01:02:06.0000] <howdoi>
https://github.com/npm/docs/issues/131 hmm

[01:31:48.0000] <annevk>
hgl: really want either JakeA or Domenic

[01:31:53.0000] <annevk>
hgl: I'm staying out of it

[02:06:50.0000] <smaug____>
annevk: apparently webkit/blink has some rather specialized unbind hook for certain things, https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Document.cpp&q=nodeWillBeRemoved&sq=package:chromium&dr=CSs&l=3728

[02:08:47.0000] <smaug____>
called in https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/ContainerNode.cpp&sq=package:chromium&dr=CSs&l=664&rcl=1438193817

[02:11:14.0000] <smaug____>
oh well

[02:17:01.0000] <JakeA>
hgl: the plan is for .cancel to signal disinterest for that promise. If all child promises signal disinterest, the initiator is notified and may take action, eg cancel the request or stream

[02:18:27.0000] <JakeA>
Any promise may cancel itself, but only a special subclass may be signalled for disinterest (CancelablePromise). If an API returns a cancelable, and you don't want that, you can Promise.resolve it

[02:27:41.0000] <hgl>
JakeA, but that makes promises a two-way communication mechanism. it greatly complicates promise objects. I think promise consumers should simply be observers. observing and signaling shouldn't be multiplexed, it will make promises very hard to reason about.

[02:30:11.0000] <JakeA>
hgl: var p = fetch(url).then(r => r.json()), then later p.cancel() seems pretty simple to reason about. How would you do that?

[02:31:44.0000] <hgl>
should the r => r.json function also be notified that p has canceled?

[02:32:15.0000] <hgl>
or only the initiator get the canceling signal?

[02:37:58.0000] <hgl>
JakeA, also, if all consumers are disinterested in the result of fetching, it doesn't necessarily mean the fetching should be canceled, what if a new consumer is attached later that want to get the result? does a canceled promise mean a rejected promise? can a new consumer get the resolved value from a canceled promise?

[02:39:16.0000] <JakeA>
hgl: the pending promise gets the "all disinterested" signal

[02:39:26.0000] <hgl>
the cancel method seems to be doing two things at once: abort the action, signal disinterest. i think this is bad, these two intentions should be expressed by two different apis.

[02:39:46.0000] <JakeA>
A cancelled promise neither rejects or resolves, but it will "finally"

[02:40:43.0000] <JakeA>
hgl: the cancel method signals disinterested, but the pending promise may react to total disinterest.

[02:40:48.0000] <JakeA>
How would you do it?

[02:40:59.0000] <JakeA>
(given the example above)

[02:43:00.0000] <hgl>
JakeA, i gave the code examples in that gist, if you want to abort, expose the abort method with a controller or on the request or something, if you want to show disinterest, "deregister" the callback added by then()

[02:44:20.0000] <JakeA>
hgl: that doesn't cover the example above where I want to cancel the request and/or the response. Can you show how *that* would work?

[02:47:40.0000] <hgl>
i don't understand. by "cancel the request", you mean abort the request? that's done by the separate abort method. by "cancel the response", you deregister then(), so the promise is never resolved. what it doesn't cover?

[02:50:56.0000] <JakeA>
hgl: can you gist it? Something that will abort the request, if it's pending, or abort the stream read to JSON, if that's pending.

[02:52:02.0000] <hallvors>
annevk: I guess https://github.com/whatwg/fetch/issues/37 requires some followup-changes in the XHR test suite. Can you report an issue on syncing tests with your spec changes, and I'll try to get to it? :)

[02:54:24.0000] <annevk>
hallvors: https://github.com/w3c/web-platform-tests/issues/2042

[02:54:48.0000] <hallvors>
annevk: thanks :)

[02:55:15.0000] <hgl>
JakeA, sure, i can try. but my point is that promise should not be used to transfer signals back up. you can always rely on a separate api to cancel the action, i think both initiating the request and read stream are actionss performed by an initiator that can be aborted. i will send you the gist soon.

[02:56:31.0000] <JakeA>
hgl: yeah, if we're going to speak in terms of what's easy to "reason about", I'd like to see code

[03:04:21.0000] <hgl>
JakeA, i think this is one way: https://gist.github.com/hgl/6778051c1386dde04ecc

[03:04:29.0000] <JoWie>
How are static interface members defined in IDL? such as Node.ELEMENT_NODE

[03:06:00.0000] <Ms2ger>
JoWie, `const`

[03:06:24.0000] <Ms2ger>
interface Node

[03:06:24.0000] <Ms2ger>
 : EventTarget {

[03:06:24.0000] <Ms2ger>
  const unsigned short ELEMENT_NODE = 1;

[03:07:32.0000] <JoWie>
ah thanks

[03:09:29.0000] <JakeA>
hgl: so request.abort would abort either the request or body stream?

[03:11:59.0000] <hgl>
JakeA, request.abort should only abort the request, once the request is aborted, fetch().then(callback), callback shouldn't not be called, since the promise is now rejected.

[03:12:43.0000] <JakeA>
hgl: so how do I cancel req.json()

[03:13:08.0000] <hgl>
you mean res.json()?

[03:13:09.0000] <annevk>
JoWie: they are deprecated

[03:13:17.0000] <annevk>
JoWie: so please don't invent new ones

[03:13:27.0000] <annevk>
JoWie: really needs to be legacyconst

[03:13:51.0000] <JoWie>
annevk: yes i just saw that

[03:14:33.0000] <annevk>
JoWie: when in doubt, use enum

[03:14:44.0000] <JoWie>
i assume anything "static" is a no go?

[03:15:03.0000] <Ms2ger>
No, static methods/attributes are fine

[03:15:04.0000] <annevk>
JoWie: no, there's static properties and methods

[03:15:06.0000] <hgl>
JakeA, i'm sorry i never used res.json(), what does it do? get json from request? what does that mean?

[03:15:16.0000] <hgl>
*req.json()

[03:15:19.0000] <JoWie>
ah, that is great

[03:15:35.0000] <annevk>
JoWie: e.g., https://notifications.spec.whatwg.org/#notification

[03:19:15.0000] <JoWie>
what is the process for suggesting a new feature (DOM) ? just open an issue on github?

[03:19:57.0000] <hgl>
JakeA, can we use some general example? i don't use fetch extensively, don't understand all its details. but with the ability to abort the action with a separating api and the ability to deregister the callbacks added to a promise. what usages do you think are still not covered but needed?

[03:20:45.0000] <hgl>
s/usage/use cases/

[03:26:07.0000] <annevk>
JoWie: yeah, though be sure to read the WHATWG FAQ entry on new features too, if you haven't

[03:29:05.0000] <JakeA>
hgl: res.json reads the body stream, parses as json, and resolves with a JS object representing the JSON response

[03:29:33.0000] <hgl>
JakeA, oh, i see, req.json reads POST data. then req.abortData() to abort stream and req.abort() to abort request, I don't think the abort apis matter here.

[03:29:51.0000] <JakeA>
I did mean res.json

[03:30:03.0000] <hgl>
as long as they are separate from the promise, and only exposed by the initiator.

[03:30:18.0000] <JakeA>
So fetch(url).then(r => r.json()) returns a promise that resolves with the JS object

[03:30:50.0000] <JakeA>
hgl: so I'd have to call two methods to cancel that?

[03:31:57.0000] <hgl>
JakeA, i probably missed something. you want to do two different things, abort the request, and abort the reading of post data, what's wrong with two methods for two different things?

[03:32:21.0000] <JakeA>
hgl: no it's reading the response data, not the request data

[03:32:56.0000] <JakeA>
req.json() is reading request data, res.json() is reading response data

[03:33:39.0000] <JakeA>
So fetch(url).then(r => r.json()) is "make a request to url, then read the response body as JSON"

[03:33:54.0000] <hgl>
yes, so what do you want to abort?

[03:35:01.0000] <hgl>
request data is post data right?

[03:35:22.0000] <hgl>
having meal, brb.

[03:35:57.0000] <JakeA>
hgl: the request data is irrelevant here. I want to abort the request or reading the response, whatever's still happening.

[03:36:46.0000] <hgl>
JakeA, request.abort()/ response.abort()

[03:38:02.0000] <JoWie>
annevk: i will

[03:38:04.0000] <JakeA>
hgl: ah, so I'd have to call both?

[03:40:36.0000] <hgl>
JakeA, if you want to abort both, maybe, but i think abort the request makes fetch return a rejected promised, so you won't have access to response i think.

[03:41:41.0000] <hgl>
brb

[03:43:41.0000] <annevk>
https://twitter.com/codinghorror/status/626638134617485312 reminds me more of Theme Hospital than anything else

[04:08:20.0000] <hgl>
JakeA, i might be wrong about returning a rejected promise. the request can be aborted later than the fetch is returned. but what about exposing a method like request.deepAbort() that when called, aborts the corresponding response too if it's still pending. However, my point is that work should not be done to investigate how promise.cancel() should work, but to design apis to abort the initiator's action directly.

[04:16:53.0000] <hgl>
however, i think promise.cancel is actually a pretty good name to deregister callbacks. promise.cancel(res, rej) returns nothing, and won't call res and rej when promise is either resolved or rejected. maybe a corresponding .uncatch() too?

[04:20:54.0000] <hgl>
i mean promise.then(res, rej); promise.cancel(res, rej); works like promise.then(res, rej) never happened. although you can create child promises with promise.then(res, rej).then(); promise.cancel(res, rej), but they will never be resolved / rejected.

[04:20:55.0000] <JakeA>
hgl: gotta run, but thanks for the feedback. Will ping you when we have something further to show. Another possibility is go make promise cancelability opt-in via fetch options

[04:21:26.0000] <hgl>
JakeA, great, nice talking to you. :)

[04:44:48.0000] <JonathanNeal>
terinjokes:

[04:44:53.0000] <JonathanNeal>
would you share your version?

[05:34:52.0000] <annevk>
https://twitter.com/reybango/status/626540556630540288 o_O

[05:35:44.0000] <annevk>
Apple and Microsoft folks having some kind of pissing context on Twitter

[05:35:57.0000] <annevk>
Ah, over prefixes, joy

[05:38:28.0000] <jgraham>
Yeah, what could possibly go wrong, discussing a inflammatory topic on the worst communication medium yet invented

[06:13:13.0000] <beverloo>
oh fancy annevk

[06:13:16.0000] <beverloo>
yay for promises :)

[06:13:26.0000] <beverloo>
let me make that change in Blink

[06:14:12.0000] <annevk>
beverloo: it's basically identical to https://storage.spec.whatwg.org/#dom-storagemanager-requestpersistent except for deprecatedCallback (and therefore the task queueing)

[07:02:30.0000] <wanderview>
JakeA: it seems res.json() aborting might also interact with res.body.cancel() once streams land?  not sure you can do res.body.cancel() if the stream is already locked by .json()

[07:02:49.0000] <wanderview>
Domenic: ^^^

[07:36:02.0000] <SimonSapin>
annevk: Do you know which part of IDNA is supposed to add the xn-- prefix? Neither Punycode or UTS46#ToASCII seem to do it

[07:36:44.0000] <annevk>
/me looks

[07:38:50.0000] <annevk>
SimonSapin: o_O

[07:38:51.0000] <SimonSapin>
looks to me like possibly a bug in ToASCII

[07:39:23.0000] <annevk>
SimonSapin: use the form at the bottom of http://www.unicode.org/reporting.html and record the URL you get back

[07:39:51.0000] <annevk>
SimonSapin: you might want to file an issue against URL too just so we track it until it's fixed there

[07:39:55.0000] <TabAtkins>
JoWie: Re: how are static interface members defined in IDL, it's by doing the API right and not using statics for constants (use enums instead)

[07:40:18.0000] <SimonSapin>
annevk: http://www.unicode.org/reports/tr46/#Processing decodes punycode when it finds a xn-- prefix

[07:40:18.0000] <JoWie>
TabAtkins:

[07:40:27.0000] <JoWie>
TabAtkins: yea it was not intended for an enum

[07:40:34.0000] <JoWie>
the reason why i was asking i mean

[07:40:42.0000] <SimonSapin>
annevk: will do

[07:42:31.0000] <beverloo>
annevk, "It is much nicer and has no side effects, such as playing sounds or vibrating the device again." depends on the renotify flag

[07:43:44.0000] <annevk>
beverloo: hmm good point, file a bug?

[07:43:51.0000] <beverloo>
I'll send a PR

[07:43:52.0000] <annevk>
beverloo: I guess renotify is not actually defined then

[07:44:12.0000] <beverloo>
I think renotify is fairly clear on what it does

[07:44:28.0000] <beverloo>
"When set indicates that the end user should be alerted after the replace steps have run."

[07:44:38.0000] <beverloo>
it's just that sentence that should clarify that said behavior may be changed

[07:45:00.0000] <annevk>
well ideally replace steps say something about it too

[07:45:19.0000] <annevk>
e.g. invoke some algorithm that the display steps use too

[07:45:28.0000] <annevk>
and that algorithm takes care of sounds, vibration, etc.

[07:45:44.0000] <annevk>
and for the replace steps the algorithm is conditional

[07:46:30.0000] <beverloo>
hmm, yes. I guess the UA doesn't have to fetch the "sound" resource for replacements if renotify=false

[07:47:02.0000] <beverloo>
(assuming it knows something's about to be replaced)

[07:48:18.0000] <annevk>
hmm yeah

[07:49:24.0000] <SimonSapin>
annevk: I’m on http://www.unicode.org/cgi-bin/processErratum.pl , it doesn’t give anoher URL

[07:49:43.0000] <SimonSapin>
It just says "Your message has been posted to the Unicode office staff."

[07:50:05.0000] <annevk>
oh

[07:50:22.0000] <annevk>
I thought last time I got some URL where my feedback was located

[07:50:35.0000] <annevk>
but perhaps that's after they email you back and say your feedback has been recorded

[07:50:40.0000] <annevk>
it's been a while

[07:51:03.0000] <SimonSapin>
I used "Type of Message: Error Report (Standard, Data files, etc)"

[07:52:06.0000] <annevk>
seems correct

[07:53:40.0000] <annevk>
SimonSapin: https://github.com/whatwg/url/issues/53

[07:54:37.0000] <annevk>
would have been nice if that was issue 46

[07:54:48.0000] <SimonSapin>
eh :)

[07:55:12.0000] <beverloo>
annevk, #50. I have some time to work on a PR.

[07:55:27.0000] <annevk>
beverloo: ta

[08:09:34.0000] <philipj>
annevk: would element.setAttribute("ontouchmove", "event.preventDefault()") also throw? setting attributes never throws...

[08:23:39.0000] <annevk>
philipj: that's a good point, I guess we'd have to make adding the listener a no-op though

[08:23:50.0000] <annevk>
philipj: would make for a somewhat funky attribute...

[08:24:32.0000] <philipj>
this mayCancel thing is harder than it first seemed :)

[08:24:46.0000] <philipj>
gotta go home!

[08:26:20.0000] <annevk>
philipj: mayCancel -> passive

[08:26:49.0000] <annevk>
philipj: but yeah, it's far from trivial

[08:27:37.0000] <annevk>
philipj: for new event APIs btw, https://github.com/zenparsing/es-observable/blob/master/dom-event-dispatch.md seems promising

[08:37:52.0000] <smaug____>
annevk: any feedback to w3c Bug 28920?

[08:38:10.0000] <smaug____>
/me also wonders how to get any fixes to HTML spec atm

[09:03:05.0000] <smaug____>
does anyone recall if wpt has any good consistent testing for structure clone use in various cases

[09:03:10.0000] <smaug____>
I assume no

[09:09:54.0000] <jgraham>
smaug____: There are a few things https://github.com/w3c/web-platform-tests/tree/e5e8fb9ebc4d5b2220abff5679fa0781c01f2c05/workers/semantics/structured-clone

[09:10:42.0000] <jgraham>
https://github.com/w3c/web-platform-tests/blob/e5e8fb9ebc4d5b2220abff5679fa0781c01f2c05/old-tests/submission/Microsoft/structuredclone/structuredclone_0.html

[09:14:19.0000] <smaug____>
both seem to be only about worker + SC

[09:14:30.0000] <smaug____>
but there is also window<->window messaging

[09:14:40.0000] <smaug____>
and push/replaceState etc

[09:30:07.0000] <Domenic>
wanderview: can you file that question on GitHub so I don't forget it? TC39 week this week.

[10:12:54.0000] <wanderview>
Domenic: https://github.com/yutakahirano/fetch-with-streams/issues/51

[12:13:47.0000] <Domenic>
wanderview: thanks for taking up that whatwg/streams video issue, it seems really interesting from skimming during the meeting and i'm sad i haven't been able to really get into it

[12:24:42.0000] <gsnedders>
is there any implementation of the legacy colour parsing rules in Python?

[12:35:01.0000] <wanderview>
Domenic: I don't think I understand what that guy wants... going to wait until you can read it

[12:40:28.0000] <jyasskin_w>
annevk or others: Do we have a convention for algorithms that take a lot of parameters? I have a couple candidate formats at https://rawgit.com/jyasskin/web-bluetooth-1/removed-attributes/index.html#dom-bluetoothgattservice-getcharacteristic.

[12:41:53.0000] <jyasskin_w>
I'm leaning toward the function call/blockquote style.

[12:42:44.0000] <annevk>
jyasskin_w: I suspect we haven't really established a winning convention yet

[12:42:53.0000] <annevk>
jyasskin_w: well I know, not suspect

[12:43:03.0000] <jyasskin_w>
Do you have a preference? :)

[12:43:40.0000] <annevk>
jyasskin_w: what I suspect is that some future iteration of the style in https://streams.spec.whatwg.org/ will be dictated by IDL

[12:44:13.0000] <annevk>
jyasskin_w: which I guess argues for your second example, minus the named parameters

[12:44:29.0000] <Domenic>
annevk: meh... no IDL types there, so not as applicable to jyasskin_w's question

[12:44:40.0000] <annevk>
(respec has kind of terrible FOUC btw)

[12:45:17.0000] <jyasskin_w>
Re FOUC: yeah, I'm probably going to switch to Bikeshed next week.

[12:45:24.0000] <annevk>
\o/

[12:45:54.0000] <annevk>
Domenic: nevertheless, still seems like the most likely style that we can adopt for IDL

[12:46:03.0000] <annevk>
Domenic: but I guess time will tell

[12:46:03.0000] <jyasskin_w>
Streams doesn't have many functions with >2 parameters either, so maybe I can argue that we should allow named parameters. :)

[12:47:11.0000] <jyasskin_w>
It is the names that push for the multi-line format. I can remove them if folks prefer it.

[12:48:52.0000] <annevk>
jyasskin_w: extreme example would be Fetch I guess, which requires passing in an object

[12:49:11.0000] <annevk>
jyasskin_w: and then the object consists of dozens of members

[12:54:16.0000] <jyasskin_w>
Yeah. This is weird again because some of the arguments in this BT algorithm are not JS objects. I guess I'll go with the Streams style + named parameters for now, and I can change it if IDL converges to something else.

[12:55:56.0000] <jyasskin_w>
Thanks

[13:09:51.0000] <Lorin>
Hi all~

[13:10:22.0000] <Lorin>
Since background-position-x / y isn't heavily supported are there talks re: allowing inherit/initial in background-position when mixed with specific measurements?

[13:10:31.0000] <Lorin>
eg. background-position:-32px inherit;

[15:32:36.0000] <rcombs>
not quite WhatWG material, but does anyone know who I should talk to to try to advance this? https://datatracker.ietf.org/doc/draft-combs-http-indeterminate-range/

[15:42:27.0000] <gsnedders>
rcombs: find out if it's been discussed on any IETF WG mailing list for a start (there's a search list function now!)

[15:43:11.0000] <gsnedders>
rcombs: try and at least skim what's gone on

[15:43:25.0000] <rcombs>
gsnedders: I've had some conversation about it on the HTTP WG list, but it's kinda just sat there since April


2015-07-31
[23:01:42.0000] <annevk>
rcombs: I learned recently that even basic HTTP range support in Gecko is not great

[23:01:57.0000] <annevk>
rcombs: e.g., no support for multiple ranges in the cache

[23:02:30.0000] <rcombs>
not a single implementation I'm aware of even parses the Accept-Ranges header per the spec

[23:02:35.0000] <rcombs>
they all shortcut it in some way

[23:05:31.0000] <annevk>
Yeah, so it seems unlikely they're interested at this point in complicating their setup

[23:06:36.0000] <annevk>
It's usually a good idea to try to improve interoperability of the current situation, before adding new features

[23:06:59.0000] <annevk>
E.g., by contributing to web-platform-tests

[23:10:44.0000] <annevk>
miketaylr: https://github.com/Fyrd/caniuse/issues/1768 :-/

[01:03:02.0000] <annevk>
JakeA: https://github.com/whatwg/fetch/issues/93

[01:16:11.0000] <annevk>
MikeSmith: https://github.com/whatwg/platform.html5.org/pull/11

[01:16:15.0000] <annevk>
MikeSmith: any ideas?

[01:16:31.0000] <annevk>
MikeSmith: I think we should just have one link for Media Queries

[01:18:13.0000] <MikeSmith>
annevk: I agree with you

[01:18:43.0000] <MikeSmith>
About the caniuse thing, he needs to talk to Fyrd I guess

[01:18:53.0000] <MikeSmith>
and I wish him luck

[01:19:29.0000] <annevk>
Yeah, no luck for being mean on prefixes

[01:59:36.0000] <annevk>
Going to retweet that ReSpec advice from @WHATWG since that's been the unofficial motto of this channel for years

[02:13:47.0000] <annevk>
MikeSmith: I updated a whole bunch of old links in platform.html5.org

[02:13:58.0000] <annevk>
MikeSmith: and merged four PRs

[02:14:26.0000] <annevk>
oh, looks like there's another 3 PRs, I guess I can do those too

[03:05:10.0000] <JakeA>
annevk: ta, will pick this up now. Back in the country fightin' jetlag

[03:05:54.0000] <annevk>
JakeA: hehe

[03:06:11.0000] <annevk>
JakeA: seems like you had a good conference

[03:07:25.0000] <JakeA>
annevk: yeah, one of the best tbh (and took a couple of days to explore Austin) - shame you weren't there

[03:08:59.0000] <annevk>
Could maybe try next year. I didn't know about it and would've been somewhat impossible with my partner being abroad at the moment

[03:55:34.0000] <JakeA>
annevk: <link rel="preload" href="/blah" as="image"> - does this have a context of image or preload?

[04:13:26.0000] <s_bash>
\who

[04:41:46.0000] <s_bash>
\part

[04:41:50.0000] <s_bash>
\quit

[05:07:34.0000] <annevk>
JakeA: undefined

[05:46:31.0000] <MikeSmith>
annevk: thanks (platform.html5.org PRs)

[05:47:39.0000] <annevk>
MikeSmith: there's a new one if you're up for it

[05:48:08.0000] <MikeSmith>
ook will check

[06:51:06.0000] <annevk>
JakeA: you can't distinguish <form> from <a> for a whole bunch of cases

[06:51:30.0000] <annevk>
JakeA: I like your general setup though

[06:51:42.0000] <annevk>
JakeA: some merger of that and what igrigorik proposed seems reasonable

[06:52:04.0000] <JakeA>
annevk: when would you want to distinguish the two?

[06:52:13.0000] <annevk>
JakeA: for CSP

[06:52:54.0000] <JakeA>
annevk: yeah, that's why I said CSp would need a bit for form submission. Although I wish they'd just redefine in terms of what the page can post/get

[06:52:55.0000] <annevk>
JakeA: it's not entirely clear to me why https://w3c.github.io/webappsec/specs/content-security-policy/#directive-form-action exists, mind you, but it does...

[06:53:02.0000] <JakeA>
hah

[06:53:04.0000] <JakeA>
snap

[06:53:42.0000] <annevk>
It's the only value that tries to tackle navigation and does it poorly...

[06:54:39.0000] <annevk>
JakeA: so navigation you'd discover through request.clientType === "document"

[06:55:00.0000] <JakeA>
annevk: or "child-document"

[06:55:07.0000] <annevk>
oh

[06:55:43.0000] <annevk>
perhaps that should be a distinct axis? the nesting...

[06:56:21.0000] <JakeA>
yeah, probably, was trying to avoid a new thing that only applied to documents, but maybe isTopLevel makes a return

[06:57:48.0000] <annevk>
I guess it's either that or isNavigation makes a return

[06:57:50.0000] <annevk>
meh

[07:02:42.0000] <JakeA>
annevk: for what it's worth, given the use case of showing a fallback page, I probably wouldn't want that for iframes

[07:40:33.0000] <annevk>
JakeA: what if it's a third-party iframe?

[07:41:43.0000] <JakeA>
annevk: hmm, yeah, I guess in that case I'd do the same as if I was opened as top-level (thinking of disqus)

[07:41:51.0000] <annevk>
or youtube.com

[07:42:02.0000] <JakeA>
yeah

[07:45:13.0000] <annevk>
So if that's the use case you probably want some context about your ancestors

[07:46:15.0000] <annevk>
Maybe pass on ancestorOrigins

[07:46:59.0000] <annevk>
Or only use "nested-document" when same-origin... Otherwise "document"

[07:47:11.0000] <annevk>
But that seems ugly

[08:07:19.0000] <miketaylr>
annevk: "Having to use a prefix is a minor inconvenience"... short term thinking there.

[08:15:11.0000] <annevk>
yeah I don't even

[08:21:20.0000] <beverloo>
annevk, updated the PR. It'll take another iteration, sorry :)

[08:21:35.0000] <beverloo>
annevk, also, Chrome now returns a Promise for requestPermission(). I'm sending out a PSA later today

[08:21:52.0000] <annevk>
heh that was quick

[08:22:04.0000] <beverloo>
It's a trivial change

[08:22:13.0000] <annevk>
review might have to wait until Monday

[08:22:24.0000] <beverloo>
No worries, nobody implements this yet

[08:22:43.0000] <beverloo>
I'm on holiday from Wednesday until the 24th btw

[08:23:14.0000] <annevk>
nice

[09:29:11.0000] <ccardona-work>
Good morning WHATWG crew o/

[11:35:02.0000] <TabAtkins>
SimonSapin (or others who might know): Rust does function overloading on return type as well as argument types. How does it handle functions called only for their side effects, whose return values aren't assigned to anything?  Do you have to declare your function as such?

[11:42:36.0000] <TabAtkins>
SimonSapin: Never mind, I found it - you return () if you don't declare anything, and are treated as assigning to a () type if you call as a statement.

[14:33:00.0000] <SimonSapin>
TabAtkins: There is no overloading, but the return type can be generic. If there is not enough context to infer the concrete type for a given call, it’s a build error and you need to add some type annotations.

[14:38:25.0000] <SimonSapin>
TabAtkins: str::parse is such a function: http://is.gd/o2gEG1 http://doc.rust-lang.org/std/primitive.str.html#method.parse

[16:34:11.0000] <Domenic>
annevk_ or otherwise: anyone know where exactly HTML monkey-patches ES to override the global `this` binding?

[16:49:05.0000] <TabAtkins>
SimonSapin: "overloading" is exactly what Rust does, unless you're being pedantic. Multiple definitions of the same function, distinguished by their signatures.