2015-02-01
[16:32:46.0000] <TabAtkins>
"Results in nothing" is pretty rare on Google.


2015-02-02
[16:30:55.0000] <GPHemsley>
Just a reminder to annevk and others: Please use spaces in wiki page titles. CamelCase is unnecessary and makes things harder to search for.

[00:01:19.0000] <annevk>
http://xkcd.com/1481/ :-)

[00:12:06.0000] <annevk>
Whoa, Googlebot only just added support for TLSv12

[00:12:54.0000] <annevk>
Would have been nice if Adam Langley had pointed that out while telling everyone only TLSv12 is cryptographically secure

[00:25:20.0000] <dbz>
Hello

[00:26:33.0000] <dbz>
I'm having trouble with my canvas element. I want it to be full screen, and when I set height/width to 100%, then the things the canvas draws also get bigger

[00:27:19.0000] <dbz>
To be specific, I'm trying to turn this game I made into a phonegap app: http://dbz.github.io/BubbleChain/

[00:27:41.0000] <dbz>
And when I make the canvas height/width 100%, then the balls get huge and don't act like the walls are the walls

[04:45:59.0000] <ondras_>
so, <my-element> and <div is=my-element> are mutually exclusive, right? My custom element is unable to support both invocations?

[04:47:16.0000] <annevk>
ondras_: not sure what you mean

[04:47:36.0000] <ondras_>
okay

[04:48:00.0000] <ondras_>
so, if I do registerElement(, {extends:...})

[04:48:06.0000] <ondras_>
I need to use @is

[04:48:13.0000] <ondras_>
and the <my-element> version does not work

[04:48:29.0000] <ondras_>
if I omit "extends", it goes the other way around

[04:48:34.0000] <ondras_>
at least in chrome canary.

[04:48:59.0000] <annevk>
sounds about right

[04:49:16.0000] <ondras_>
"My custom element is unable to support both invocations?"

[04:49:20.0000] <ondras_>
does this question make sense now?

[04:49:22.0000] <annevk>
I don't think we should do is="", we should make MyElement extends HTMLDivElement work

[04:49:35.0000] <annevk>
ondras_: yeah I guess, I don't really see it as invocations

[04:49:49.0000] <ondras_>
okay, blame my poor english skills then

[04:49:51.0000] <ondras_>
my point is

[04:49:54.0000] <ondras_>
what shall I do?

[04:50:01.0000] <ondras_>
as an author of a custom element

[04:50:07.0000] <ondras_>
shall I use "extends" or not?

[04:50:59.0000] <annevk>
ondras_: not sure, neither Apple nor Mozilla is interested in supporting the current prototype-based custom elements

[04:51:27.0000] <ondras_>
ah

[04:51:31.0000] <ondras_>
dammit :)

[04:51:51.0000] <ondras_>
looks like the hype wave already took off; this will probably be a hard landing for many

[04:52:51.0000] <annevk>
ondras_: I wrote some blog posts and there's also https://wiki.whatwg.org/wiki/Custom_Elements

[04:53:09.0000] <annevk>
ondras_: and over a hundred emails on public-webapps

[04:54:56.0000] <ondras_>
annevk: right. the amount on public-webapps is staggering. I follow that group but I am reluctant to read that much mail .)

[04:55:45.0000] <ondras_>
annevk: anyway, thanks for the info about status quo

[07:27:11.0000] <ondras_>
is there any js api to access and modify styling for ::before and ::after pseudo-elements?

[07:28:33.0000] <zcorpan>
ondras_: not really, but you can add a rule to a stylesheet to style them

[07:29:04.0000] <zcorpan>
ondras_: what are you trying to do?

[07:31:35.0000] <ondras_>
zcorpan: change the "color" css property of a ::before element :/

[07:31:41.0000] <ondras_>
but the color is js-generated, unfortunately

[07:31:46.0000] <ondras_>
so I am out of options, apparently

[07:32:14.0000] <ondras_>
scoped stylesheets are no longer supported, iirc?

[07:32:37.0000] <zcorpan>
i mean you can add a rule to a stylesheet with JS

[07:32:46.0000] <zcorpan>
or modify an existing rule

[07:33:07.0000] <ondras_>
right

[07:33:37.0000] <ondras_>
well say I have ten <div>s and I want to modify the ::before of one particular div

[07:33:50.0000] <ondras_>
those are not divs, those are my custom elements

[07:33:58.0000] <ondras_>
I have no control about their count, IDs and so on

[07:34:55.0000] <annevk>
ondras_: there's a proposal to expose them I think, but not in current browsers

[07:35:06.0000] <annevk>
ondras_: but then custom elements are not cross browser either :-)

[07:35:27.0000] <ondras_>
well, obviously. but the polymer's platform.js works quite okay

[07:44:49.0000] <annevk>
Domenic: so if custom-button { @extends button } can be done automatically, what is left?

[07:45:39.0000] <annevk>
Domenic: basically replacing the localName checks with something that looks like instanceof but is really ignoreRealmInstanceOf

[07:45:51.0000] <annevk>
Domenic: right?

[07:46:02.0000] <Domenic>
annevk: focus, a11y, a few other things

[07:46:08.0000] <annevk>
Domenic: the only fallback you miss at that point is non-script fallback

[07:46:12.0000] <annevk>
Domenic: why would that be gone?

[07:46:22.0000] <Domenic>
annevk: getting a button's CSS doesn't give you its focus behavior...

[07:46:36.0000] <annevk>
Domenic: yes, but if it's a proper subclass you should get that

[07:46:54.0000] <Domenic>
well, maybe, but you'd have to modify the focus spec for that

[07:46:55.0000] <annevk>
Domenic: and if you update the localName checks elsewhere with ignoreRealmInstanceOf

[07:47:21.0000] <Domenic>
better to add an extensible focus mechanism so that you don't have to subclass a focusable element to get focus behavior

[07:47:28.0000] <annevk>
Domenic: is there anything in the focus spec that would require something else from modifying a localName check?

[07:47:43.0000] <annevk>
Domenic: that seems separate

[07:47:49.0000] <Domenic>
it would be better if focus spec was like https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit# so that it checked el.isTabStop()

[07:48:04.0000] <Domenic>
then isTabStop() behavior is inherited if you inherit from the HTMLButtonElement prototype

[07:48:08.0000] <Domenic>
But also could be configured separately

[07:48:19.0000] <annevk>
I don't disagree with any of this

[07:48:25.0000] <Domenic>
heh ok

[07:48:29.0000] <annevk>
However, I'm not sure why that has to be done first

[07:48:50.0000] <Domenic>
i guess the idea is that if you actually make all these things extensible then you don't need any local name *or* ignoreRealmInstanceOf checks

[07:49:05.0000] <Domenic>
You use inherited protocols for all of them, instead of switch statements

[07:49:13.0000] <Domenic>
Polymorphism etc. etc.

[07:49:16.0000] <annevk>
Getting from <input is=x-x> to <x-x> was two things I thought. Style and localName checks.

[07:49:45.0000] <annevk>
Okay, so that would be an alternative way to get there

[07:49:52.0000] <annevk>
But that seems more invasive on the short term

[07:49:56.0000] <Domenic>
agreed

[07:50:05.0000] <Domenic>
trying to think if there was anything more. which i guess was your original question.

[07:50:13.0000] <annevk>
:-)

[07:51:11.0000] <Domenic>
i think for a sufficiently expansive definition of "localname checks" (which might be broader than the amount of times implementations check localNames) that is correct

[07:51:34.0000] <Domenic>
E.g. I don't think implementations have a switch(localName) to assign accessibility behavior

[07:52:07.0000] <Domenic>
and specs say "<button> behaves like this"

[07:52:20.0000] <Domenic>
you'd have to modify it to say "HTMLButtonElement and any inheritors behave like this"

[07:52:50.0000] <Domenic>
the switch(localName)s, in specs at least, appear in only a few cross-cutting places, like IIRC focus

[07:56:15.0000] <annevk>
One other problem with this is <input> btw. Ideally you'd subclass one of the types, not <input> in general. But I guess there's not really a way around that.

[07:56:24.0000] <annevk>
Even better would be <input type=my-custom> maybe?

[07:56:51.0000] <annevk>
Has the same graceful degradation

[07:57:28.0000] <annevk>
Yeah, for specifications we want a phrase for "button-and-subclasses elements"

[07:59:15.0000] <Domenic>
hmmmm I like this <input type="my-custom"> idea...

[07:59:21.0000] <Domenic>
Seems hard to make work

[07:59:31.0000] <Domenic>
But it's true that type="" is kind of the is="" of 1999

[08:00:05.0000] <Domenic>
On the other hand we only have one HTMLInputElement constructor/prototype.

[08:22:47.0000] <annevk>
Domenic: yeah, HTML's design and JavaScript's object model are not a great match

[08:27:52.0000] <hemanth>
> But it's true that type="" is kind of the is="" of 1999 <- history repeats ?

[08:28:40.0000] <annevk>
Domenic: e.g. even if you offered some kind of solution specific to <input>, you still couldn't subclass <input type=password>

[08:28:51.0000] <annevk>
Domenic: it'll always be a little bit weird

[13:23:33.0000] <dglazkov>
https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/ is great


2015-02-03
[16:26:54.0000] <gsnedders>
Bah, coming up with a good title for a Stack Overflow question of "my mod_rewrite rules don't do what I want" is hard. :(

[18:03:03.0000] <GPHemsley>
/me wonders if there was an incident recently

[23:57:51.0000] <mathiasbynens>
Hixie: why are `minlength` & `maxlength` specced to count 16-bit code units rather than code points? https://html.spec.whatwg.org/multipage/forms.html#attr-fe-maxlength

[00:09:38.0000] <annevk>
mathiasbynens: that's what implementations do iirc

[00:09:55.0000] <annevk>
mathiasbynens: although I think WebKit might not, there was some discussion about it

[00:10:44.0000] <mathiasbynens>
annevk: isn’t `minlength` “new”? hmm, even then i guess consistency with `maxlength` is worth something

[00:11:01.0000] <annevk>
yeah, that's why

[00:11:34.0000] <annevk>
it's unclear why you'd count code points though

[00:11:43.0000] <annevk>
bytes would make some sense historically

[04:28:06.0000] <mathiasbynens>
yeah, almost anything other than 16-bit code units would make more sense :)

[04:28:20.0000] <mathiasbynens>
but… topic

[04:46:41.0000] <smaug____>
is Brian Kardell ever on irc?

[04:58:02.0000] <MikeSmith>
smaug____: no, Brian isn't usually aroun on IRC

[04:58:12.0000] <MikeSmith>
or maybe never

[04:58:44.0000] <MikeSmith>
can't recall if I ever remember chatting with him on IRC anywhere

[04:59:22.0000] <smaug____>
k

[04:59:27.0000] <smaug____>
/me sends email

[05:06:54.0000] <smaug____>
...saying nothing new

[05:35:30.0000] <annevk>
smaug____: I hope that we can finish custom elements as a standalone thing first, but it might make sense to figure out how to better support encapsulation in shadow DOM

[05:43:30.0000] <annevk>
https://twitter.com/IgorZIJ/status/561902586631303168 SoundScript is some kind of asm.js competitor?

[05:50:02.0000] <smaug____>
annevk: yup

[05:50:10.0000] <smaug____>
to the earlier comment

[05:50:41.0000] <smaug____>
hmm, what is SoundScript

[05:50:49.0000] <smaug____>
sounds like some audio handling thingie

[05:50:52.0000] <smaug____>
but probably isn't

[05:50:54.0000] <annevk>
smaug____: only one browser shipped so far...

[05:51:19.0000] <annevk>
smaug____: from the surrounding tweets and the dslomov commenting I'm pretty sure it's not about audio

[05:51:48.0000] <annevk>
s/the dslomov/dslomov/

[06:20:20.0000] <caitp>
annevk: was there any attempt to add progress notifications to fetch? seems unfinished :(

[06:30:31.0000] <MikeSmith>
RSConf looks like a fun event https://twitter.com/182debrin/status/561811081564131328/photo/1

[06:33:03.0000] <MikeSmith>
apparently some people are starting to use the term HTML6 non-ironically https://twitter.com/hashtag/html6?src=hash

[06:34:21.0000] <caitp>
HTML2016 �

[06:36:43.0000] <jgraham>
MikeSmith: Yeah I was having my own personal WTF moment about that

[06:37:02.0000] <jgraham>
and then I saw http://t.co/sLHt8HjjFp and my head exploded

[06:37:11.0000] <gsnedders>
oooh, HTML6 again!

[06:38:32.0000] <caitp>
wow jgraham

[06:39:02.0000] <jgraham>
http://joostvanmeeteren.info/informatics/introduction_to_html6.html

[06:39:17.0000] <caitp>
on the bright side at least the zombies didn't win

[06:39:49.0000] <darobin>
/me discreetly purchases xhtml3.com

[06:42:06.0000] <MikeSmith>
for lots more wtf see http://www.realcombiz.com/2014/10/the-expected-specifications-of-html6.html

[06:42:27.0000] <MikeSmith>
which appears to be a re-blog of something from somewhere else maybe

[06:42:38.0000] <MikeSmith>
but regardless it's .. baffling

[06:43:32.0000] <MikeSmith>
"With HTML6, we’re going to have namespace elements like: <html:media type=”video”>, <html:title>."

[06:43:55.0000] <MikeSmith>
is that coming from some trollish thing that people are taking seriously?

[06:44:13.0000] <gsnedders>
It seems to be from http://html6spec.com?

[06:44:25.0000] <caitp>
as long as it prevents another zombie apocalypse, it's all good, bring on the namespaces

[06:46:01.0000] <jgraham>
http://xahlee.info/comp/html6.html is exciting

[06:46:22.0000] <jgraham>
In the future you will need a custom keyboard layout just to type HTML

[06:47:55.0000] <caitp>
such a modest proposal

[06:48:04.0000] <MikeSmith>
gsnedders: ah

[06:50:13.0000] <MikeSmith>
jgraham: oh man the Questions ＆ Answers part of http://xahlee.info/comp/html6.html is solid gold

[06:53:10.0000] <MikeSmith>
anyway you can type 「 and 」 easily from a Japanese IME, so as long as we'll be requiring authors to use a Japanese IME we might as well go all the way and use Japanese for all the element names and attribute names

[06:54:35.0000] <caitp>
that would probably make a lot of people very happy and encourage a lot of people to become web developers

[06:54:51.0000] <darobin>
with judicious Kanji we might be able to make every single element and attribute name single-character

[06:54:59.0000] <MikeSmith>
oh wait I see even the parens are not parens they're LEFT/RIGHT TORTOISE SHELL BRACKET

[06:55:02.0000] <darobin>
I mean talk about terse

[06:55:15.0000] <darobin>
it's so terse it's torterse

[06:55:17.0000] <MikeSmith>
darobin: yeah

[06:55:19.0000] <MikeSmith>
hahah

[06:55:38.0000] <annevk>
caitp: that's because it's not finished

[06:56:07.0000] <Ms2ger>
darobin, anything you want to say before I close https://github.com/w3c/web-platform-tests/issues/1484 ?

[06:56:13.0000] <annevk>
caitp: I recommend studying https://github.com/yutakahirano/fetch-with-streams/ for the tentative plan

[06:56:17.0000] <MikeSmith>
of course the logical place we're going to end up here is don't use kanji for element/attribute names  but go all the way and just use emoji

[06:56:48.0000] <darobin>
Ms2ger: I should probably look at it, but if you really want to close it I can't say I care that much

[06:56:55.0000] <Ms2ger>
OK

[06:57:17.0000] <darobin>
I'm disappointed that it hasn't addressed the custom elements issue simply through use of the astral plane

[06:57:37.0000] <MikeSmith>
annevk: speaking of Streams, has anybody started to implement it in gecko yet

[06:57:45.0000] <MikeSmith>
and if so is there a tracking bug

[06:57:46.0000] <darobin>
emoji is sure to attract a lot of people to coding

[06:57:53.0000] <annevk>
MikeSmith: not that I know of

[06:57:57.0000] <MikeSmith>
ok

[06:58:07.0000] <annevk>
MikeSmith: might be a good idea to file a tracking bug

[06:58:23.0000] <MikeSmith>
ok will do a right now

[06:58:26.0000] <annevk>
ta

[06:59:02.0000] <caitp>
annevk is it problematic that blink might ship it early then, in case it needs to change more fundamentally?

[06:59:18.0000] <annevk>
caitp: streams?

[06:59:21.0000] <caitp>
fetch

[06:59:42.0000] <annevk>
caitp: oh, I did not mean not finished in that way

[07:00:26.0000] <annevk>
caitp: the way fetch() is designed right now seems as close to perfect as we could get without streams; and the design does not preclude adding them later

[07:02:00.0000] <MikeSmith>
annevk: what component for Streams? DOM or JavaScript Engine or ...?

[07:02:15.0000] <MikeSmith>
/me looks around for smaug too

[07:02:18.0000] <annevk>
MikeSmith: heh

[07:02:22.0000] <caitp>
i dunno, the example looks kinda sub-optimal :(

[07:02:33.0000] <annevk>
MikeSmith: both DOM and JavaScript :/

[07:02:39.0000] <MikeSmith>
yeah

[07:02:48.0000] <annevk>
caitp: what example?

[07:02:57.0000] <caitp>
on the github page you linked

[07:03:54.0000] <annevk>
caitp: that's mostly the streams API, no?

[07:04:56.0000] <caitp>
sure, but it doesn't really look very good, as an api, it doesn't really integrate well with promises

[07:05:12.0000] <caitp>
the subscription model doesn't fit well there

[07:05:22.0000] <caitp>
ehhh it's awkawrd

[07:05:42.0000] <annevk>
So did we change subjects from whether fetch() is shippable to whether streams is done?

[07:05:58.0000] <caitp>
i think when it comes to fetch they're sort of tied, no?

[07:06:26.0000] <annevk>
Currently fetch() doesn't expose streams, so no

[07:06:45.0000] <MikeSmith>
annevk: file https://bugzilla.mozilla.org/show_bug.cgi?id=1128959

[07:06:48.0000] <MikeSmith>
*filed

[07:06:57.0000] <caitp>
if it ships now, people start using it, and then in m44 or m56 they start exposing streams, that seems potentially bad

[07:07:14.0000] <MikeSmith>
annevk: I put it under DOM: Core & HTML

[07:07:40.0000] <MikeSmith>
I'll wait for smaug to move it out to the JavaScript component :)

[07:08:02.0000] <annevk>
caitp: you might be on to something, but this is not very concrete

[07:08:31.0000] <annevk>
MikeSmith: cool, next time just put it in "DOM", the subcomponents are rather useless

[07:08:44.0000] <MikeSmith>
oh

[07:08:49.0000] <MikeSmith>
ok

[07:08:57.0000] <Ms2ger>
Well, DOM vs DOM: C&H at least

[07:09:30.0000] <caitp>
okay, so lets say right now, i'm used to my promise being resolved when the request completes, because that's just how it is since there's no way to subscribe to progress notifications or explicitly ask for streaming

[07:09:39.0000] <caitp>
then all of a sudden, it starts being resolved very early before everything is done

[07:09:43.0000] <caitp>
the response isn't what i expect it to be

[07:09:58.0000] <caitp>
and, i haven't explicitly subscribed to streaming anywhere

[07:10:32.0000] <caitp>
just doesn't seem right

[07:10:59.0000] <MikeSmith>
Ms2ger: annevk the Component Description for "DOM" doesn't provide such great guidance to bug submittors: 「For bugs in DOM support which do not fit into any other DOM Component. This is the right component for issues with <base href=""> and xml:base. 」

[07:11:18.0000] <Ms2ger>
It hasn't been updated in a long time

[07:11:51.0000] <annevk>
caitp: that part is not going to change, the promise resolving once all headers are in is exactly the right primitive to expose

[07:12:15.0000] <annevk>
MikeSmith: yeah, bothers me too

[07:12:27.0000] <annevk>
MikeSmith: I wonder if I put effort into getting it right whether that would pay off

[07:12:37.0000] <MikeSmith>
probably not worth it

[07:15:25.0000] <Domenic>
regarding streams/fetch/progress, JakeA put something together a week ago which I tidied up a bit, results in https://gist.github.com/domenic/440db8eac99c5b41bf95

[07:15:30.0000] <MikeSmith>
I doubt there are many people who just wander in and submit any bugs under components in the Core product to begin with and read the component descriptions anyway

[07:27:13.0000] <MikeSmith>
Domenic: do you know if there's a chromium/blink tracking bug for the Streams implementation

[07:28:25.0000] <MikeSmith>
I found other chromium bugs related to it but nothing for it itself

[07:35:07.0000] <MikeSmith>
the guy who wrote http://www.infoworld.com/article/2873543/html5/10-proposals-for-a-better-html6.html seems to be a time traveler from the past; e.g., "HTML6 proposal No. 2: Browser-sizing of imagery" is basically describing the <picture> element

[07:36:06.0000] <MikeSmith>
but his next-most-recent article is "PHP vs. Node.js: An epic battle for developer mind share" so maybe he's actually from another dimension

[07:37:33.0000] <MikeSmith>
"PHP and JavaScript, two partners who once ruled the Internet together"

[07:37:37.0000] <MikeSmith>
"Where PHP wins: SQL"

[07:50:12.0000] <annevk>
MikeSmith: hah

[07:53:03.0000] <MikeSmith>
annevk: about whatever SoundScript is, https://docs.google.com/presentation/d/1803sMhKjZEOSpsShfC7K7O4sl6ZltWXyQ4ego1BN-kM/edit#slide=id.g6e9e9d944_2_344

[07:54:33.0000] <MikeSmith>
is "use stricter" already a real thing being discussed

[07:56:00.0000] <gsnedders>
MikeSmith: no

[08:05:09.0000] <caitp>
it didn't really seem like a competitor to asm.js to me, because it didn't seem like it would make a real target language. but it could allow optimizing compilers to cheat a bit, possibly removing mapcheck bailouts and stuff like that? dunno too much about it though

[08:05:15.0000] <MikeSmith>
gsnedders: ok well hopefully Dmitry will get around to writing about this soon somewhere else

[08:05:25.0000] <MikeSmith>
lomov

[08:07:01.0000] <gsnedders>
MikeSmith: :)

[08:08:53.0000] <gsnedders>
caitp: depends how you handle the boundary between typed and untyped code, and how often you cross it

[08:09:17.0000] <caitp>
well it would be like, mapcheck failure -> throw, rather than deopt

[08:09:19.0000] <caitp>
or something like that

[08:09:37.0000] <caitp>
I have no idea :)

[08:10:27.0000] <MikeSmith>
from whence are you all discerning the details about the proposal?

[08:10:37.0000] <MikeSmith>
from those slides or some other writeup?

[08:11:02.0000] <caitp>
I don't have much info on it, it was talked about a few weeks ago, but no writeup or anything that I saw

[08:11:20.0000] <MikeSmith>
ah OK

[08:11:49.0000] <MikeSmith>
well from the slides I can't tell how much of it is just describing how V8 already works vs what's being proposed

[08:12:09.0000] <gsnedders>
caitp: as soon as you have the check you've lost, throwing or deopt doesn't matter

[08:12:21.0000] <caitp>
gsnedders, not necessarily

[08:13:57.0000] <caitp>
i mean the end result is you don't want to crash the browser, so somewhere along the way you need some sanitization

[08:14:04.0000] <caitp>
some of that might be able to happen statically

[08:14:37.0000] <caitp>
if it can't happen statically, you might only need to perform checks when crossing from untyped code into typed code

[08:15:04.0000] <caitp>
but yeah the whole thing is pretty fuzzy to me :p

[08:15:16.0000] <caitp>
i'm sure there will be more info as it becomes available

[08:16:12.0000] <gsnedders>
caitp: most of it can't happen statically because you don't have the level of detail needed in any sane type system, because you need to know object layouts to be useful

[08:16:30.0000] <gsnedders>
caitp: boundary checks typically end up frequent enough the gain is pretty small

[08:16:42.0000] <caitp>
we'll see

[08:17:49.0000] <gsnedders>
(Hack with only a very small perf gain for FB, simply because boundary checks were so frequent. Yes, it got better over time, but it's still not a particularly big perf gain AIUI. The big gain is statically asserting correctness properties of the codebase.)

[08:18:17.0000] <caitp>
that's certainly a big one

[08:18:59.0000] <gsnedders>
I'm not saying there aren't good reasons to add more of a type system to ES, and I think it'll happen, but you can get the correctness gains through gradual typing by and large, and without introducing another mode.

[08:19:42.0000] <caitp>
I have so little info on it, and I can't read cyrillic writing so it's hard to get much out of the presentation :p

[08:21:10.0000] <Domenic>
apparently you can't get perf gains out of a non-sound type system, so it is much less interesting to VM implementers

[08:21:37.0000] <Domenic>
My main impression of SaneScript is that, like Dart, it is a language designed with VM implementers as the highest good in the priority of constituencies.

[08:22:08.0000] <Domenic>
slides/TC39 notes should be public soon

[08:22:45.0000] <caitp>
i assume they've already lifted the lid on it if they're talking about it at rsconf

[08:23:21.0000] <gsnedders>
Domenic: pretty much

[08:35:52.0000] <MikeSmith>
Domenic: I'd hope your impression isn't correct but I guess I won't be surprised if it is

[08:36:36.0000] <MikeSmith>
but even the value proposition for asm.js doesn't seem like the greatest if you try to describe it

[08:36:55.0000] <Domenic>
yeah languages which are designed with VM implementers in mind do have good value as a compilation target.

[08:36:59.0000] <MikeSmith>
"The solution for people who want/like to write things in C++"

[08:46:24.0000] <caitp>
i still didn't really get the "compilation target" vibe from the new language modes

[08:46:44.0000] <caitp>
if that's what it sounded like at tc39 i'll take your word for it

[08:48:01.0000] <annevk>
"use stricter+types" wow

[08:48:49.0000] <annevk>
MikeSmith: it's Dmitry and Dimitri

[08:49:11.0000] <Domenic>
caitp: that's definitely not the intent, but I think it will be the effect.

[08:49:33.0000] <Domenic>
I *did* get the "these are the parts of JS we don't like optimizing" vibe

[08:50:20.0000] <annevk>
MikeSmith: heh, I stopped reading those slides due to the Russian, guess I should have persisted

[08:53:04.0000] <annevk>
Domenic: is "SoundScript" from the slides "SaneScript"?

[08:53:23.0000] <caitp>
different language modes

[08:53:30.0000] <Domenic>
Nah, SoundScript is a sound type system, and in theory could be separate from SaneScript

[08:54:33.0000] <annevk>
Ah, makes sense

[08:55:01.0000] <annevk>
Looking forward to the details

[09:00:47.0000] <MikeSmith>
I hope there's not really a trend as far as (mis)prioritization of things that lend themselves to optimization over ... just making things work well

[09:01:04.0000] <MikeSmith>
or even just prioritization of performance over all else

[09:02:50.0000] <caitp>
mobile users might be pretty keen on having their js-heavy applications work fast, and maybe yield more time to the cpu instead of doing background (or worse, serial) optimization

[09:03:03.0000] <MikeSmith>
well we are coming up on 5 years since that V8 "move DOM attributes to prototype chain" bug was first opened

[09:03:22.0000] <caitp>
yeah but isn't that more of a problem for developers rather than users

[09:03:32.0000] <caitp>
grandma doesn't care about that she just wants her email

[09:03:33.0000] <MikeSmith>
meanwhile all other JS engines implemented it per-spec years ago -- performantly

[09:04:48.0000] <Domenic>
Yeah the biggest takeaway re: SaneScript/SoundScript I think is that the V8 team working on JavaScript proper is going to be smaller again :(

[09:05:05.0000] <MikeSmith>
I think the fact that the V8 developers can't implement "move DOM attributes to prototype chain" performantly is because they've already over-optimized in such a way that their design prevents it

[09:05:07.0000] <Ms2ger>
Don't worry, SM will beat them so hard they'll have to :)

[09:05:15.0000] <Domenic>
Ms2ger: that's my hope :)

[09:05:29.0000] <caitp>
domenic i'm guessing that's more the compiler people doing that, and probably not until TF is actually fast

[09:05:33.0000] <gsnedders>
To be fair, I think a lot of the problem is that there are a lot of people in Google who want to write a new language VM rather than V8. idk.

[09:05:51.0000] <Domenic>
gsnedders: yep, feels cyclical... first dart, now this.

[09:06:12.0000] <gsnedders>
Along with requirements for the team all to be in one place, which drives some (many?) Googlers away.

[09:06:12.0000] <MikeSmith>
that's really sad if true

[09:06:40.0000] <MikeSmith>
somebody remind me what product managers are for

[09:06:46.0000] <caitp>
I don't think they're all in california or germany <_<

[09:06:49.0000] <caitp>
just most

[09:06:53.0000] <caitp>
>_-

[09:06:54.0000] <gsnedders>
(i.e., anyone who wanted to stay in Aarhus ended up working on Dart, more or less.)

[09:07:13.0000] <gsnedders>
I don't think anyone of the original Aarhus team was allowed to keep working on V8?

[09:07:23.0000] <gsnedders>
When it mostly moved to Munich?

[09:08:26.0000] <gsnedders>
AFAICT your options were: a) stay in Aarhus and work on Dart; b) move to Munich and keep working on V8; c) stay in Aarhus and move to working on something totally unrelated.

[09:08:46.0000] <gsnedders>
Which doesn't seem like the best management of the V8 project.

[09:10:27.0000] <MikeSmith>
there's management of the V8 project?

[09:11:15.0000] <Domenic>
gsnedders: I don't think that's an accurate history...

[09:12:00.0000] <caitp>
there wouldn't be much point paying for expensive campuses in different countries if you couldn't dig up peoples families to relocate them

[09:17:18.0000] <gsnedders>
Domenic: it's how I've always understood it, from what I've been told

[09:18:09.0000] <Domenic>
gsnedders: from what I've been told everyone in Aarhus wanted to move with Lars to Dart and then the V8 team had to rebuild from scratch. The initial people interested in doing so worked in Munich and built a team there.

[09:20:04.0000] <Ms2ger>
Sounds like "everyone realized how much technical debt they'd built up"

[09:22:13.0000] <gsnedders>
Domenic: I had the impression that one or two people in Aarhus would've rather stayed with V8, but couldn't move. idk.

[09:22:27.0000] <gsnedders>
Domenic: certainly, yes, the majority chose to move with Lars

[09:33:08.0000] <caitp>
is that the story behind TF?

[09:33:17.0000] <caitp>
i guess that makes sense

[09:39:08.0000] <annevk>
Domenic: it seems somewhat inevitable some kind of VM thing emerges in the end with all the compile-to-JS stuff going on, but maybe not

[09:40:19.0000] <annevk>
Domenic: that stream-based progress example does require an awful lot of code compared to the equivalent with XMLHttpRequest

[09:40:27.0000] <annevk>
Domenic: I guess the abstractions come later...

[09:44:46.0000] <caitp>
async fetch(url, options) -> Promise vs fetchStream(url, options) -> Stream, imho

[09:47:16.0000] <Domenic>
I think the Promise<Response> where response.body is a Stream is the better model.

[09:48:17.0000] <caitp>
then it's a 2-step process

[09:48:23.0000] <Domenic>
yep

[09:48:33.0000] <caitp>
I think the fact that it's a 2-step process makes it kind of unattractive :(

[10:11:21.0000] <Domenic>
caitp: I doubt you want to start reading from the body of a 404. Seems good to have a step in between.

[10:11:54.0000] <caitp>
why do you doubt that? web browsers do it

[10:12:08.0000] <caitp>
an abstraction in a framework might also want to

[10:12:50.0000] <Domenic>
Sure, then the framework can write a function

[10:13:44.0000] <caitp>
i mean yeah other people can write the abstractions for you, but it seems like the exposed API should be pretty good to begin with

[10:16:49.0000] <Domenic>
I think it is

[10:19:49.0000] <annevk>
caitp: a web browser needs to inspect response headers before processing the body

[10:20:49.0000] <annevk>
caitp: every somewhat-non-trivial HTTP API will have to do that

[10:26:06.0000] <caitp->
which is great, but it still makes for a pretty awful api

[10:38:56.0000] <annevk>
well, I guess we'll disagree on that

[11:12:52.0000] <bkardell>
smaug: http://krijnhoetmer.nl/irc-logs/whatwg/20150203#l-289

[11:13:14.0000] <bkardell>
no, it's blocked at work, but occasionally he checks the logs :)

[11:29:33.0000] <JonathanNeal>
If it’s not too intrusive … would you circumvent ad blocking software for a client? Let me know @ https://docs.google.com/forms/d/1OxPpj8ZbM1oTBS8iG4MkGNQ7tq7EEeMltEJ5tUpAmUk/viewform or to help spread the poll @ https://twitter.com/jon_neal/status/562682942682841088

[11:29:52.0000] <JonathanNeal>
s/too intrusive/too intrusive to ask

[13:29:20.0000] <jgraham>
JonathanNeal: Didn't you ask that before? :p

[13:32:09.0000] <JonathanNeal>
jgraham: yea, and by asking again, I got another 20 entries. Now, I feel like I have a comfortable sample size.

[13:33:06.0000] <jgraham>
JonathanNeal: By which you mean "a reassuringly large, but nevertheless hugely biased, sample", right? :p

[13:35:25.0000] <JonathanNeal>
jgraham: How is it hugely biased? And how would I get it not to be?

[13:35:46.0000] <jgraham>
It's hugely biased because it's self-selecting

[13:35:58.0000] <jgraham>
Only people who are interested in the answer bother to reply

[13:36:44.0000] <JonathanNeal>
I’m surprised it’s not so one-sided then https://docs.google.com/spreadsheets/d/1bSl8xyrrQ34AFcUszHBXn8riLjVpxwFUwdcetDqoTDI

[13:37:19.0000] <jgraham>
Right, but you don't know how one-sided it is compared to the true population

[13:37:54.0000] <jgraham>
e.g. if you get 50/50 and the underlying population is 90/10 then you still didn't collect useful data

[13:38:16.0000] <JonathanNeal>
jgraham: is there a way to better collect useful data? Are there such statistics already available to me?

[13:39:39.0000] <jgraham>
I don't know how to collect useful data here, unless you have some way of reaching a largely uniform sample of the population you are interested in

[13:44:51.0000] <JonathanNeal>
jgraham: would you find the reasons listed as being useful information? I found some of them very insightful, and some of them better than I am at articulating one point of view or the other.

[13:46:02.0000] <jgraham>
Yeah, so *reasons* seem like they are more useful independent of the actual yes/no answers


2015-02-04
[16:20:18.0000] <benjamingr>
Domenic: noob question here - why would you use an ID in a specification like that instead of keeping the object alive in an algorithm like that? If it leaks endless promises or endless IDs the leak is there all the same.

[16:21:37.0000] <Domenic>
benjamingr: numbers don't leak

[16:21:41.0000] <Domenic>
benjamingr: objects do!

[16:22:26.0000] <benjamingr>
What do you mean? If I have a list of numbers and that list keeps growing doesn't that leak memory? Eventually the list will consume all my heap - it'll just take longer, won't it?

[16:24:13.0000] <Domenic>
benjamingr: yes, fair. But numbers---especially "small/medium integers" (smis) in modern VMs---consume much less memory than a whole promise object.

[16:24:46.0000] <Domenic>
benjamingr: and it's not an ever-growing list we're concerned about, it's a fluctuating-in-size list

[16:25:01.0000] <benjamingr>
Right, so your process would crash later but it would crash nontheless.

[16:25:03.0000] <Domenic>
having that fluctuation be between 0 and x is much better than between 0 and 10x

[16:25:13.0000] <Domenic>
sure, if you actually leak, you crash

[16:25:33.0000] <benjamingr>
So the reason these are numbers and not objects is not not to leak it's to conserve memory?

[16:26:00.0000] <Domenic>
yeah, i guess "leak" is imprecise. More "don't keep the object alive".

[16:26:23.0000] <Domenic>
For anyone who wonders what we're talking about, it's https://gist.github.com/domenic/9b40029f59f29b822f3b#promise-error-handling-hooks-rough-spec-algorithm ... conversation started in #promises

[16:27:20.0000] <benjamingr>
Domenic:  Yeah, I figured I'd ask here and not in #promises since I'm wondering about a specification issue and how you specified it rather than about promises (do let me know if you rather have this discussion in #promises)

[16:27:31.0000] <Domenic>
nah here seems good :)

[16:30:54.0000] <benjamingr>
Oh, so it's really an observable map of `id => reason` where the id can/should be removed if a potential rejection is handled and items are added when a new potentially rejection happens. I guess that makes more sense than storing the promises anyway since there is no sync inspection API in native promises.

[16:32:07.0000] <benjamingr>
Thanks, that totally clarified why there are IDs there :)

[16:33:35.0000] <Domenic>
benjamingr: hmm yeah not sure why I didn't use the word "map" and related concepts more in that document. Would be better.

[16:34:37.0000] <benjamingr>
Well, you're probably more used to spec terminology than me, I'm assuming people more involved would have a lot less trouble reading it.

[00:17:24.0000] <annevk>
MikeSmith: do you think there's any chance for W3C Bugzilla to gain "needsinfo"?

[00:17:38.0000] <annevk>
MikeSmith: when you really want someone to answer a question, it's rather effective

[00:20:26.0000] <MikeSmith>
annevk: will see if I can add it right now

[00:20:35.0000] <annevk>
MikeSmith: no rush :-)

[00:20:58.0000] <MikeSmith>
the rush is that if I don't do it now I'll just forget :D

[00:25:14.0000] <MikeSmith>
annevk: wait there's already a resolved=NEEDSINFO status

[00:26:12.0000] <annevk>
MikeSmith: there's this feature in Mozilla Bugzilla where you can ask more information from a given Bugzilla user

[00:26:20.0000] <MikeSmith>
ahh

[00:26:53.0000] <MikeSmith>
/me peruses the parameters to see if there's a setting for it in our instance

[00:27:08.0000] <annevk>
MikeSmith: the UI phrase is "Need more information from"

[00:27:24.0000] <MikeSmith>
ok

[00:27:28.0000] <MikeSmith>
still looking

[00:32:17.0000] <Ms2ger>
annevk, MikeSmith, might be an extension

[00:32:39.0000] <MikeSmith>
yeah there's no feature for that in v4.4.8 as far as I can see

[00:32:51.0000] <MikeSmith>
but agreed it's a really useful feature

[00:32:54.0000] <MikeSmith>
so we should add it

[00:33:01.0000] <Ms2ger>
<glob> Ms2ger, its an extension, but under the hood it's a normal bugzilla flag

[00:34:15.0000] <MikeSmith>
I don't have root to install it but I could sweet talk somebody who does into installing it probably

[00:34:52.0000] <MikeSmith>
that's assuming I need shell access to the environment to install extensions

[00:35:13.0000] <MikeSmith>
I otherwise have full admin perms in the Web UI

[00:36:05.0000] <Ms2ger>
<glob> https://github.com/mozilla/webtools-bmo-bugzilla/tree/master/extensions/Needinfo

[00:36:05.0000] <Ms2ger>
<glob> hrm, although the recent addition of our mentor may have broken that claim.  if that's the case it'll be easy for us to update/fix

[00:39:02.0000] <Ms2ger>
MikeSmith, sounds like you do need root, poke glob on moznet if you have issues :)

[00:39:16.0000] <MikeSmith>
Ms2ger: hai

[01:32:36.0000] <MikeSmith>
plz-install-this-extension sysreq filed

[06:09:32.0000] <bkardell>
smaug____:  you here?

[06:10:11.0000] <smaug____>
bkardell: yes

[06:11:43.0000] <bkardell>
Hold on let me switch machines

[06:14:13.0000] <bkardell>
smaug____: You do see that .component is definitely not the same thing, right?  In terms of CSS it matches existing combinators and requires perfect coordination at all times

[06:14:53.0000] <smaug____>
yes, and >>> needs perfect coordination too if enabled by default everywhere

[06:15:20.0000] <smaug____>
I agree using .component would be more annoying, but you can still achieve pretty much the same

[06:15:28.0000] <smaug____>
bkardell: let me ask differently..

[06:15:42.0000] <smaug____>
why you want >>> to be enabled by default to all the components?

[06:15:51.0000] <bkardell>
right, and you *can* in theory totally avoid accidents in real life, but that is not reality

[06:16:55.0000] <bkardell>
so your main concern is that it should be plausible to say "your selectors are always irrelevant to me"

[06:17:14.0000] <bkardell>
is that right?

[06:18:15.0000] <smaug____>
yes, component should be able to say that

[06:18:40.0000] <bkardell>
mostly for styling or also for qsa and friends?

[06:18:45.0000] <smaug____>
but it should be also possible to say, "hey, I'm fine that you style my content "

[06:18:50.0000] <smaug____>
both

[06:18:58.0000] <bkardell>
hmm

[06:19:04.0000] <smaug____>
qsa is probably the more scary part

[06:19:12.0000] <bkardell>
more scary in terms of...?

[06:19:17.0000] <smaug____>
since if qsa can select shadow dom

[06:20:05.0000] <smaug____>
in terms of that the JS will probably then do something with the result

[06:20:12.0000] <smaug____>
like, it could move elements around there

[06:20:17.0000] <smaug____>
and break how the component works

[06:20:33.0000] <caitp>
what if it needs to

[06:20:53.0000] <bkardell>
ok, let me try this

[06:21:24.0000] <smaug____>
caitp: if the outside world needs to change the content of component, the component should give the permission

[06:21:26.0000] <caitp>
angular 1.x uses qsa to find the root element of an app to set everything up, but angular 2 has everything in components, so if the bootstrapping works the same way, it would have to be able to traverse shadow dom

[06:21:35.0000] <caitp>
it probably doesn't work the same way, but imagining it did :>

[06:21:38.0000] <bkardell>
to start, imagine you had just what I listed as the kind of bare minimum

[06:21:42.0000] <smaug____>
it is somewhat similar private:  and such in many programming languages

[06:22:05.0000] <smaug____>
if the component doesn't let you to do what you need to do with it, don't use the component

[06:22:08.0000] <bkardell>
all css problems that come 'out of the box' with existing css goes away, it becomes safe

[06:22:40.0000] <caitp>
no i expect the angular-defined components have some hook for bootstrapping

[06:22:41.0000] <bkardell>
if you wanted to prevent outside meddling, that's up to the component and they can easily trump

[06:23:08.0000] <bkardell>
!important, on the element or even just ganging up some id-based :not()

[06:24:11.0000] <bkardell>
seems that offers some pretty reasonable protections and room to grow - it's all more or less explainable with one 1 new thing

[06:24:30.0000] <jgraham>
Making encapsulation opt-in doesn't seem like a great design

[06:25:09.0000] <bkardell>
if we wanted to add something like "you may NEVER reach inside here for any purpose via tree walking of any kind"

[06:25:12.0000] <caitp>
if I use qsa from the devtools console, I don't want to be limited by the shadow barrier :p

[06:25:27.0000] <jgraham>
caitp: devtools can do whatever it wants

[06:25:33.0000] <caitp>
but in practice, they don't

[06:25:39.0000] <caitp>
in practice they're using the same DOM api :(

[06:26:00.0000] <bkardell>
jgraham: I dont think you want dev tools to do something diff than code

[06:26:20.0000] <jgraham>
devtools can already do lots of things that DOM APIs can't

[06:26:34.0000] <caitp>
well, a few things

[06:26:43.0000] <jgraham>
There's no DOM API to set a breakpoint, for example

[06:26:49.0000] <caitp>
like simulating pseudo selectors

[06:26:50.0000] <bkardell>
smaug___: how do you explain the you may never part - is it in DOM? it's unnamed?

[06:27:38.0000] <bkardell>
I guess if your combinator required a name that could maybe work

[06:27:55.0000] <bkardell>
is that what you're getting at in that email?

[06:28:27.0000] <gsnedders>
jgraham: DebugStatement?

[06:29:19.0000] <bkardell>
caitp: simulating a state is different, it's a super power - doesn't change an API

[06:29:44.0000] <caitp>
i thinkn we were talking about devtools superpowers

[06:29:47.0000] <caitp>
think*

[06:29:53.0000] <jgraham>
In any case, it's pretty clear that better, larger, web applications are going to require locality of reasoning; the ability to understand one small part of an application and treat the rest as a black box. This requires encapsulation by default and the ability to expose specific APIs for extension

[06:32:47.0000] <caitp>
do you think qsa should be able to traverse <content> elements inside a shadow tree

[06:32:54.0000] <caitp>
(does it already? it probably does)

[06:34:44.0000] <smaug____>
that is an interesting question

[06:34:47.0000] <smaug____>
I assume it doesn't

[06:36:32.0000] <smaug____>
or what does your question mean

[06:36:42.0000] <smaug____>
caitp: the contents of <content> ?

[06:36:59.0000] <smaug____>
like, all the stuff distributed there?

[06:37:14.0000] <caitp>
yeah

[06:38:01.0000] <smaug____>
well, those elements aren't children of <content>

[06:38:10.0000] <jgraham>
<content> defines an explicit extension point, so I think it isn't obviously wrong that the content is qsa-able, but it should at the very least be in the component's control

[06:38:12.0000] <smaug____>
what selector would find then

[06:38:14.0000] <smaug____>
them

[06:38:39.0000] <smaug____>
do we need some new selector there?

[06:38:41.0000] <caitp>
they're basically child elements of the component proper, which is weird since you can have multiple content elements

[06:38:51.0000] <caitp>
and you wouldn't be able to specify which one

[06:47:39.0000] <bkardell>
smaug___: replied to your post

[06:49:49.0000] <smaug____>
will read after lunch

[06:50:27.0000] <bkardell>
pretty short

[06:51:13.0000] <smaug____>
/me reads

[06:52:44.0000] <smaug____>
k

[06:52:46.0000] <bkardell>
smaug___: in short, I think the name thing is actually pretty good... it's sensible

[06:53:09.0000] <bkardell>
its a really minor tweak and easily explained

[06:53:31.0000] <smaug____>
trying to recall what TabAtkins thought about it

[06:53:32.0000] <bkardell>
has clear value

[06:54:27.0000] <bkardell>
did you discuss it here?

[06:54:47.0000] <bkardell>
I'm curious as to what you could really have against it

[06:55:04.0000] <smaug____>
I think I mentioned some of this earlier here too, when I was horrified to find /deep/ in a spec draft :)

[06:55:53.0000] <bkardell>
hmm

[06:56:33.0000] <bkardell>
something like :deep(*) would match any with a name, right?

[06:56:52.0000] <smaug____>
right

[06:57:11.0000] <bkardell>
I mean, it seems like a pretty simple safety to split the danger

[06:57:34.0000] <bkardell>
it seems really sensible to me actually

[06:57:49.0000] <smaug____>
* should make it clear to the reader that "yes, I really want all the public mounts"

[06:58:15.0000] <bkardell>
..... "that I can actually reach because they said it is ok"

[06:58:23.0000] <bkardell>
hmm

[06:58:27.0000] <bkardell>
actually...

[06:58:38.0000] <bkardell>
would this answer a question for us that we've been lacking...

[06:58:39.0000] <smaug____>
I said "public"

[06:59:00.0000] <bkardell>
like - could you almost realistically explain something like input type=slider native now if you had that

[06:59:12.0000] <bkardell>
the mount isn't public

[06:59:41.0000] <smaug____>
well, you couldn't still explain the dom side

[06:59:47.0000] <bkardell>
/me waves hand and says "pay no attention to the DOM behind the mount"

[06:59:58.0000] <bkardell>
lol

[07:00:16.0000] <bkardell>
but I mean, this seems to get us closer

[07:00:39.0000] <bkardell>
because we had no way of explaining that there were shadows you couldn't reach into (native ones)

[08:04:52.0000] <bkardell>
Domenic: "I hope others can address the question of why custom element callbacks are useful" wdym? alternative?

[08:12:19.0000] <Domenic>
bkardell: wtf you left already? Anyway in that thread rniwa was questioning whether custom element callbacks are useful so I was hoping someone would explain that to him.

[08:12:49.0000] <bkardell>
oh I see

[08:13:34.0000] <bkardell>
hey did you see smaug's post on www-style / reply?

[08:13:48.0000] <bkardell>
I think it seems sensible

[08:14:33.0000] <bkardell>
I dont think there is precedent for a combinator taking an argument, that's the only thing really - but there's no precedent of a combinator doing something with a non-element either, so...

[08:31:32.0000] <Domenic>
bkardell: I still don't really understand why there's such insistence on truly-encapsulated stuff being the default. Seems to miss the point of your post about friendly fire etc. I haven't seen authors asking for that kind of thing (the cases that do want it, such as ads or social buttons, are happy with <iframe>s), and the only use case I can see for it is

[08:31:33.0000] <Domenic>
HTML as Custom Elements. Which is important, but seems backward in priority of constituencies.

[08:32:22.0000] <Domenic>
bkardell: kind of comes down to whether shadow DOM is an authoring aid (= composition) or an implementation strategy (= encapsulation).

[08:32:52.0000] <smaug____>
composition as such can be done without shadow DOM

[08:33:42.0000] <bkardell>
I agree that I doubt it will be the common case, but I can imagine some where I want to be kind of explicit about it because it is just too fundamental to my function - a graphing control maybe, for example

[08:33:51.0000] <smaug____>
and I think the complexity of shadow DOM doesn't quite make sense if all it gives is helping with composition

[08:34:51.0000] <jgraham>
It seems to me that techniques that allow you to reason about less of a system at once are authoring aids

[08:35:53.0000] <jgraham>
That is the central benefit of encapsulation.

[08:35:56.0000] <bkardell>
I explcitly tried to not use the term shadow dom because I'm talking about minimal - not event retargeting, not projection, etc -- just one simple primitive that can host a subtree and provide a new 'not quite an element'... that doesn't actually seem that complex

[08:37:55.0000] <smaug____>
anyhow, I could possible live with default-to-public-visibility in the CSS case. It is error prone, but if someone can actually think of good reasoning for it, fine.

[08:38:15.0000] <Domenic>
jgraham: yes, fair. But perhaps when I say "composition" I mean "Java-style encapsulation"---still available with reflective APIs, but not by default.

[08:38:17.0000] <smaug____>
bkardell: yeah, sorry if I've been talking in shadow DOM terms

[08:39:21.0000] <bkardell>
Domenic: the ad is really minimal, it makes sense conceptually and the delta in implementation is primarily about what a combinator matches and doesn't.  We can theorize and debate all day, but isn't it better to just say "ok, if people think that could be useful, there's really no harm and it might be good to give a tool which also helps explain more of

[08:39:21.0000] <bkardell>
native and gives authors one more lever to experiment with"

[08:39:23.0000] <Domenic>
jgraham: in that sense I am talking about mostly-encapsulation as an aid for composing parts of the system, precisely because you can reason about less of the system at once (and can assume that if someone is messing with you they really know what they're doing)

[08:39:45.0000] <dglazkov>
smaug____: I am curious how you reached this conclusion on composition primitives being unimportant. In my experience, all of the evidence that I see points at nearly the opposite.

[08:39:56.0000] <dglazkov>
it's okay if this is just a hunch

[08:40:08.0000] <smaug____>
dglazkov: where have I said they are unimportant

[08:40:15.0000] <Domenic>
dglazkov: yeah, I saw "They could simply use their own framework or library" as "They could simply switch to another platform" -_-

[08:40:35.0000] <dglazkov>
but if you look at the stuggles of modern libraries, _all_ of them are primarily trying to solve composition

[08:40:43.0000] <smaug____>
I'm saying they aren't important enough to legitimate the complexity of shadow DOM

[08:41:07.0000] <dglazkov>
again, how do you draw the line in the sand?

[08:41:15.0000] <dglazkov>
what _is_ important enough?

[08:42:53.0000] <smaug____>
well, shadow DOM is in all levels very complicated (specs and implementation issues are a good signs of that). To legitimate that all I sure hope it brings in some new functionality to the platform, not just help script libraries a bit to let their implementation to be a tad simpler.

[08:42:53.0000] <dglazkov>
as far as I can see, style composition is one the largest unsolved problems in the web platfrom

[08:43:58.0000] <dglazkov>
smaug____: I see. So if this is not a new capability, it's not as interesting?

[08:44:43.0000] <bkardell>
hmm.. I honestly dont mean to sound dismissive of anyone's claims here, and I dont get the sense that smaug___ meant it quite as bluntly as he initially stated it,  but in my experience dismissing the composition problem as "kinda easily" solvable with todays powers strikes me as out of touch and I'd hope we could avoid stating it that way (because it was

[08:44:44.0000] <bkardell>
just done again on www-style)

[08:44:50.0000] <smaug____>
it can be interesting still, but as I said, shadow DOM is very complicated. Makes implementations and specs more complicated (and a bit slower too)

[08:45:04.0000] <smaug____>
so it all it gives is some small aid... then is it really worth

[08:45:09.0000] <smaug____>
s/it/if/

[08:45:28.0000] <dglazkov>
smaug____: it seems you're pre-judging the size of the aid?

[08:45:40.0000] <smaug____>
maybe

[08:45:49.0000] <dglazkov>
you don't really have to go far, just look at the state of CSS testing for web apps

[08:45:52.0000] <jgraham>
Domenic: I don't think we should start by designing a system that gives full control to anyone who thinks that they know what they are doing. It seems like a better approach to start with something that provides more encapsulation and figure out how to turn off the safety catches later.

[08:46:08.0000] <dglazkov>
today, it's basically a lost cause

[08:46:48.0000] <jgraham>
In general I think when we have done that in the past it's been a better outcome than when we have taken an open system and tried to band-aid on extra constraints with features like CSP

[08:46:54.0000] <Domenic>
jgraham: I guess I just disagree. I think we should start by designing a system useful to the majority and then maybe design a system for the smaller case. E.g. I don't think Java ever got around to designing a reflection-proof private, which speaks to how important that problem really is.

[08:47:04.0000] <dglazkov>
jgraham: I completely disagree

[08:47:39.0000] <dglazkov>
I don't think we should start with a goal of designing a system open or closed

[08:47:57.0000] <jgraham>
You disagree that places where we have enforced e.g. the cross origin policy have aged better than places where we did not and are trying to fix it up with opt-ins afterwards?

[08:48:01.0000] <dglazkov>
it should be driven by how the system helps the developer

[08:49:46.0000] <dglazkov>
jgraham: I genuinely don't know if CSP in particular is going to be harmful or useful on the long run.

[08:53:17.0000] <dglazkov>
shadow dom started pretty closed up. Then we actually asked devs to use it and the first thing to go were the hard boundaries.

[08:53:39.0000] <jgraham>
On its own that doesn't say anything

[08:53:42.0000] <dglazkov>
anytime you want to introspect anything, hard boundaries are just unnecessary obstructions

[08:54:24.0000] <dglazkov>
annevk, Domenic: changing subject a tiny bit -- have we considered how importNode and cloneNode work with almost-sync constructors?

[08:54:28.0000] <jgraham>
Right, but there's a difference between e.g. being able to inspect things and being able to change them

[08:55:24.0000] <dglazkov>
jgraham: yes. However, we don't really have a concept of read-only DOM in the platform today

[08:55:46.0000] <dglazkov>
jgraham: smaug____ is complaining about complexity already, imagine how much more complexity it would be to add something like that.

[09:08:24.0000] <annevk>
dglazkov: that's a good question

[09:08:33.0000] <annevk>
dglazkov: it would be easy for the parser, but for the DOM...

[09:08:50.0000] <annevk>
dglazkov: (though parser-wise, sync would be easy, not sure about almost-sync)

[09:09:39.0000] <annevk>
/me is behind on everything, will try to catch up tomorrow

[14:52:33.0000] <TabAtkins>
Why is everyone named Glen weird?

[14:52:42.0000] <TabAtkins>
Apologies to people named Glen here, BUT STILL.

[14:53:18.0000] <hober>
maybe we need namespaces to disambiguate glens

[14:54:13.0000] <caitp>
why apologize? that's like the highest compliment

[14:54:34.0000] <caitp>
glen would be honoured I'm sure

[14:57:56.0000] <tantek>
this whole channel is weird

[15:00:07.0000] <dglazkov>
DNS

[15:00:23.0000] <dglazkov>
I am so sorry


2015-02-05
[16:05:42.0000] <smaug____>
/me mumbles something to TabAtkins ;)

[16:06:42.0000] <smaug____>
one day I'll figure out why Google is so against any talk about encapsulation, which is a thing other vendors have brought up so often

[16:07:02.0000] <smaug____>
oh well

[16:14:48.0000] <caitp>
does it ever weird you out that if one employee of an organization, even if they're not in a management position, has an opinion on something, it is often taken to mean "Organization X has opinion Y"

[16:15:16.0000] <caitp>
or even if they are in a management position, in some cases

[16:55:33.0000] <TabAtkins>
smaug____: If you're getting "Tab doesn't care about encapsulation" when my message is very explicitly "stop ignoring composition", um?

[16:58:08.0000] <TabAtkins>
I also explicitly said "there are valuable isolation use-cases", but I did it in a later reply and I"m not sure of the time ordering of this IRC convo and the email, so you get a pass. ^_^

[00:22:51.0000] <annevk>
Domenic: is anyone playing with your Streams polyfill?

[00:32:02.0000] <zcorpan>
how does one upload things to w3cmemes these days?

[00:37:39.0000] <annevk>
not sure, judging by the memes sgalineau__ prolly knows

[01:27:25.0000] <annevk>
dglazkov: thanks again for raising that cloning question, that might be what everyone needed to buy into the Dmitry solution (or come up with something super clever, we'll see)

[02:40:12.0000] <zcorpan>
i wonder when the firefox logo becomes flat

[02:40:48.0000] <zcorpan>
or maybe firefox will outlive the flat trend

[02:41:34.0000] <annevk>
Did https://blog.mozilla.org/creative/2013/06/27/a-new-firefox-logo-for-a-new-firefox-era/ not make it flat enough?

[02:43:36.0000] <annevk>
zcorpan: not even Opera downloads are distributed over TLS

[02:45:43.0000] <zcorpan>
annevk: oh ok, i guess i missed the change

[02:45:53.0000] <zcorpan>
annevk: that's a known issue

[02:46:16.0000] <annevk>
zcorpan: I guess it's still not really flat, it curves a bit around the globe

[03:16:02.0000] <jgraham>
   

[05:04:39.0000] <JonathanNeal>
Is there a specific property in the works for making something visually hidden but available to screen readers? It’s often brought up as something needed, but there’s no clean solution http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/ http://snook.ca/archives/html_and_css/hiding-content-for-accessibility

[05:04:39.0000] <JonathanNeal>
http://webaim.org/techniques/css/invisiblecontent/

[05:14:30.0000] <annevk>
JonathanNeal: technically that should still be display:none

[05:14:52.0000] <annevk>
JonathanNeal: but I guess there's rampant abuse that makes that impractical?

[05:16:19.0000] <Ms2ger>
Screen readers don't read display:none content, AIUI

[05:19:28.0000] <JonathanNeal>
And [hidden] computes to display:none so we’re really out of luck.

[05:26:33.0000] <JonathanNeal>
I’m looking for something like [offscreen]

[05:31:59.0000] <annevk>
Screen readers are so tricky. They sort of want the layout tree exposed, but the standards are designed with the idea that they get the content tree...

[05:32:32.0000] <annevk>
And all the advocacy is rather similar, e.g. "designing for Google" is like designing for a screen reader...

[05:32:54.0000] <annevk>
Now soon that may be true given that Google is starting to use "headless" browsers, but still

[05:37:22.0000] <JonathanNeal>
annevk: hmm, the usual visually-hidden block looks like rect(0px 0px 0px 0px); position: absolute; — I wonder if I could just stick that on [aria-visible]:not([aria-visible="false"]):not(:active):not(:focus)

[05:40:21.0000] <JonathanNeal>
Or [aria-hidden=“false”]:not(:active):not(:focus)

[05:46:44.0000] <bkardell>
JonathanNeal: why the need for the nots there?

[05:47:55.0000] <JonathanNeal>
bkardell: in less-often cases where a visually hidden element is focusable, it is usually desired to have the element become visually shown to the user. skip to links fall into this category.

[05:48:56.0000] <JonathanNeal>
That was phrased poorly, I’m sorry. When an element is both visually-hidden and focusable, like skip-to links at the top of a page, then the desired effect is usually to have them become visible on focus.

[06:10:42.0000] <bkardell>
hmm I see

[06:17:02.0000] <annevk>
welcome bkardell \o/

[06:17:10.0000] <bkardell>
lol

[06:17:21.0000] <bkardell>
I don't start work for another 2 hours :)

[06:28:06.0000] <JakeA>
annevk: Is there a time you can make a call about ServiceWOrker & postMessage?

[06:29:38.0000] <annevk>
JakeA: today and tomorrow are rather tricky, some visitors so have stuff going on in the evening

[06:30:24.0000] <JakeA>
annevk: ok, will try and rearrange. Alex is in the UK so could do something earlier, although that'll be tricky for Jonas if you think he needs to be part of it

[06:32:57.0000] <annevk>
JakeA: I still think talking to Hixie will likely go much better

[06:33:08.0000] <annevk>
JakeA: he has thought up the entire postMessage() system afaik

[06:39:59.0000] <JakeA>
annevk: ok, I'll see if I can pin him down for a meeting

[06:57:58.0000] <jsx>
Any idea about the status of @counter-style implementation in Chrome and IE?

[06:58:21.0000] <jsx>
I checked status.modern.ie and chromium bug list, but no info there.

[07:02:11.0000] <caitp>
what does @counter-style mean

[07:03:17.0000] <jsx>
It lets you define custom counter styles for lists.

[07:03:21.0000] <jsx>
described here - http://dev.w3.org/csswg/css-counter-styles-3/#at-ruledef-counter-style

[07:08:26.0000] <caitp>
tab would probably know if there's been anything about that started

[07:10:32.0000] <jsx>
looking forward to hear from him or someone in the chrome team

[07:37:25.0000] <Domenic>
annevk: some Node people have used it (and one caused feedback into the spec). I've been meaning to make demos using it for a while---the spec even contains examples for web socket streams. And, this week I am investigating adapting it into a patch for V8.

[07:37:46.0000] <annevk>
interesting

[08:10:31.0000] <wanderview>
/me almost types Demonic instead of Domenic in a bug...

[08:13:02.0000] <Domenic>
spellcheckers hate him

[08:23:20.0000] <hemanth>
/me nmotw: Use a ES6 map, like an Object! -> http://nmotw.in/objectmap/   

[08:25:26.0000] <hemanth>
Complete one year since /me start nmotw.in did not miss a week, 48 modules and counting ^_^ ...

[09:52:42.0000] <JakeA>
Hixie: any availability for a call on ServiceWorker & postMessage. We've got a bit stuck on https://github.com/slightlyoff/ServiceWorker/issues/609

[10:00:53.0000] <Ms2ger>
Inviting Hixie for sync communication?

[10:01:06.0000] <Ms2ger>
That's an interesting strategy, let's see how it plays out

[10:02:12.0000] <JakeA>
Yeah, I used deliberately incorrect punctuation in that message to baffle him into agreeing

[11:55:16.0000] <JonathanNeal>
Does anyone know ways to identify content as assistive-only aka offscreen aka visually-hidden (not necessarily a way to style it, but a way to communicate it in the document)?

[12:41:00.0000] <Domenic>
TabAtkins: I think we should copy your namespaces post into the WHATWG wiki somewhere

[12:49:30.0000] <TabAtkins>
Domenic: Feel free.

[14:34:33.0000] <annevk>
GPHemsley: can you get the wiki account Domenic tied to Domenic's email address somehow?

[14:34:42.0000] <annevk>
GPHemsley: it's not entirely clear to me how to edit an existing user

[14:39:00.0000] <tantek>
annevk: you have to dig into the MediaWiki install to find a magic PHP script to do the right MySQL voodoo

[14:39:36.0000] <annevk>
Yeah, GPHemsley knows how it works

[14:39:58.0000] <annevk>
I tried searching around, but didn't really get anywhere

[15:09:35.0000] <Hixie>
JakeA: i'm not up to date on the serviceworker stuff, but i'm happy to advise within that constraint

[15:09:51.0000] <Hixie>
JakeA: what's the problem?

[15:10:13.0000] <Hixie>
Domenic: you got wiki issues i hear?

[15:45:47.0000] <Domenic>
Hixie: yeah, I tried to forgot-password for Domenic and didn't get any email. also tried emailing wiki-admin and got a weird error.


2015-02-06
[16:29:04.0000] <GPHemsley>
annevk: Sure, I'll take a look

[16:51:21.0000] <GPHemsley>
annevk, Domenic: For reasons unknown, there is no way to change a user's e-mail address without editing the database directly.

[16:51:34.0000] <GPHemsley>
annevk, Domenic: I have done so, and sent a new password reset e-mail.

[16:51:53.0000] <GPHemsley>
annevk, Domenic: If this turns out to be a bogus request, though, it's on you. ;)

[17:00:32.0000] <Domenic>
GPHemsley: thanks! All sorted.

[17:01:48.0000] <GPHemsley>
cool

[22:37:40.0000] <JonathanNeal>
This was an excellent discussion. https://bugzilla.mozilla.org/show_bug.cgi?id=946370

[22:40:17.0000] <JonathanNeal>
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#screenreader this addresses my need to identify content for screenreaders.

[00:27:24.0000] <annevk>
Hmm, I guess I should start writing a wiki page for Shadow DOM too with a summary of all those emails

[00:27:32.0000] <annevk>
75 emails

[00:29:01.0000] <othermaciej>
I should read them all and say something constructive instead of just snarking

[00:36:27.0000] <annevk>
My main takeaway is that event retargeting is contentious

[00:36:35.0000] <annevk>
Encapsulation is still a problem

[00:37:11.0000] <annevk>
And per rniwa I get the impression that there are some aspects of the current design that prevent isolation

[00:38:04.0000] <annevk>
I've unfortunately poorly kept track of Shadow DOM discussion to date so I would have to do some digging

[00:38:35.0000] <annevk>
I guess I might start doing that soonish

[00:42:44.0000] <othermaciej>
the current design doesn’t have isolation

[00:43:01.0000] <othermaciej>
I don’t think it would be that hard to add

[00:43:27.0000] <othermaciej>
making it the default (as I think it should be) would probably require a compat break with what what shipped in Chrome

[00:44:19.0000] <annevk>
othermaciej: actual isolation requires something worker-like though, no?

[00:44:30.0000] <othermaciej>
oh, really real isolation?

[00:44:32.0000] <othermaciej>
not really

[00:44:38.0000] <othermaciej>
I am not sure why people suggest that at all

[00:44:48.0000] <annevk>
The +1 button?

[00:44:51.0000] <othermaciej>
the actual UA doesn’t use workers to implement built-in elements

[00:45:02.0000] <othermaciej>
there’s no need to have a separate thread of control

[00:45:09.0000] <annevk>
Well yeah I don't mean workers per se, I just mean that the globals can't reach each other

[00:45:18.0000] <othermaciej>
you just need a two-way membrane and separate global objects

[00:45:30.0000] <annevk>
Workers have that the best, the <iframe> setup is rather special

[00:45:40.0000] <othermaciej>
assuming you want to protect the component from the page

[00:46:08.0000] <annevk>
So Gecko has a really cool membrane setup as I understand it, but nobody else is interested in adopting it

[00:46:15.0000] <othermaciej>
basically the way the page could attack the component is by pre-hacking the JS global environment (for example modifying methods on prototypes), or by passing it poison values

[00:46:38.0000] <othermaciej>
you can solve the first by giving a component (or maybe set of components loaded from a given origin) its own global object

[00:47:06.0000] <annevk>
So in your estimation we just need to tweak the existing shadow DOM a bit?

[00:47:11.0000] <othermaciej>
and the second either by using very crude message passing, or by making method/property access do an extended version of the structured clone algorithm at the boundaries

[00:47:40.0000] <othermaciej>
it’s been a while since I looked into the details of what it would take to provide just the DOM level of encapsulation

[00:47:53.0000] <othermaciej>
but once you have that, you need a way to instantiate components from a separate global

[00:48:02.0000] <othermaciej>
I don’t think Shadow DOM quite has that in scope

[00:48:20.0000] <othermaciej>
I always imagined some form of cross-domain safe thing like HTML imports where you can also import custom elements from it

[00:48:32.0000] <othermaciej>
and those custom elements have all their JS run in a separate global object with the membrane thing

[00:48:54.0000] <annevk>
Okay so yeah, you're looking at something quite different then compared to what is there now

[00:48:57.0000] <othermaciej>
Adam Barth sort of agreed a while ago that this basic plan could lead to the possibility of sound two-way isolation

[00:49:18.0000] <othermaciej>
I think the shadow DOM piece is mostly right (except for its failure to do DOM encapsulation)

[00:49:25.0000] <othermaciej>
doing script isolation requires a separate mechanism

[00:49:34.0000] <othermaciej>
you can’t tack it onto shadow DOM

[00:49:44.0000] <othermaciej>
because by the time you have some script creating a shadow DOM, it’s too late

[00:49:49.0000] <othermaciej>
so the mechanism has to come in earlier than that

[00:50:46.0000] <othermaciej>
I sort of explained it in this email: https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0024.html

[00:50:56.0000] <annevk>
This all sounds quite familiar

[00:51:15.0000] <othermaciej>
it sounds like XBL2

[00:52:39.0000] <annevk>
Heh

[00:52:55.0000] <othermaciej>
here’s Adam more or less agreeing that my approach is a sensible general direction: https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0038.html

[00:53:57.0000] <annevk>
Did he ever report back?

[00:54:08.0000] <othermaciej>
not that I recall

[00:54:24.0000] <othermaciej>
I think he might be mostly working on a non-Blink project these days

[00:54:50.0000] <annevk>
I got that impression too, hardly see him around anymore

[01:00:17.0000] <annevk>
I love the latest objection against deprecating synchronous XMLHttpRequest. "Do you really want script writers to deal with scroll events while an ajax is outstanding?"

[01:02:23.0000] <othermaciej>
I am terrified of the mindset that would produce that comment

[03:21:51.0000] <JakeA>
annevk: tried to sum up the postMessage stuff over at https://github.com/slightlyoff/ServiceWorker/issues/609#issuecomment-71622477 - let me know if I've gotten any of it wrong

[03:22:18.0000] <JakeA>
annevk: I'm going to try and get this in front of external devs looking to implement push messaging for their take

[03:27:02.0000] <annevk>
JakeA: I don't see how you can communicate with Worker and SharedWorker "the standard way"

[03:27:39.0000] <annevk>
JakeA: it's also not clear to me that complex library usage is going to be discovered early on in the deployment of this, that seems overly optimistic

[03:28:21.0000] <annevk>
JakeA: I also suggested actually having a MessagePort like object on each side on a per-client basis

[03:28:31.0000] <JakeA>
annevk: I thought you said it was ok to have instance of dedicatedworker in the serviceworker, and have postMessage work. The standard way with SharedWorker would be the connect event and passing ports through (which I dislike, but it's how it's defined)

[03:28:41.0000] <annevk>
JakeA: so the object that receives the message can also send is, which happens to be how most of these postMessage() APIs work

[03:29:02.0000] <annevk>
JakeA: I did at one point, but then later on we figured out that it couldn't possibly work...

[03:29:32.0000] <annevk>
JakeA: A SW instantiating a Worker/SharedWorker is different from it controlling one

[03:30:42.0000] <JakeA>
annevk: ohh, I thought it was the other way around, that you thought it couldn't work then realised it could. If a SW gets a reference to a DedicatedWorker via the clients API, what stops it being able to postMessage to it?

[03:31:08.0000] <annevk>
JakeA: how can two windows possibly have a Worker object that references the same worker?

[03:31:34.0000] <annevk>
JakeA: s/two windows/two globals/

[03:34:09.0000] <JakeA>
Seems like I'm misremembering the history of the dedicated worker bit

[03:34:35.0000] <JakeA>
annevk: how about SharedWorkers? No problem exposing those right?

[03:34:40.0000] <annevk>
Same problem

[03:34:49.0000] <annevk>
I mean, we talked about this, I'm not sure what to say

[03:35:14.0000] <annevk>
I said several times that Window, Worker, and SharedWorker all need a way, the same way, to receive and post messages to their SW

[03:42:37.0000] <JakeA>
Fair, I guess getting a SharedWorker would need to be equivalent to constructing a SharedWorker, which could call the connect event, which doesn't really make sense

[03:47:30.0000] <annevk>
Exactly

[03:48:00.0000] <annevk>
And DedicatedWorker cannot suddenly go from 1:1 to 1:2

[03:52:50.0000] <JakeA>
annevk: "I also suggested actually having a MessagePort like object on each side on a per-client basis" - you weren't happy with navigator.serviceWorker.onmessage being that thing right?

[03:53:12.0000] <annevk>
JakeA: well, if we always have navigator.serviceWorker.postMessage() to go with it, sure

[03:53:17.0000] <annevk>
also*

[03:53:28.0000] <annevk>
I don't really care where we place the endpoints

[03:57:16.0000] <JakeA>
annevk: The problem is we need to land the message on the client somewhere client specific, a ServiceWorker instance isn't that. But posting from page to ServiceWorker should be serviceWorker.postMessage. SharedWorker gets around this using the connect & posts model which is horrible but also doesn't work with SWs because SWs terminate

[03:59:02.0000] <JakeA>
annevk: navigator.serviceWorker.onmessage has the benefit of being client specific, lives in ServiceWorker-API space, doesn't interfere with things like window.onmessage, but it doesn't meet the navigator.serviceWorker.postMessage requirement as there no sensible place for that to post to

[04:48:49.0000] <beverloo>
annevk, is there a mozilla bug for SWR.showNotification()?

[04:56:39.0000] <annevk>
beverloo: I'm not sure, feel free to file one

[04:57:08.0000] <annevk>
/me finds https://bugzilla.mozilla.org/show_bug.cgi?id=531817 but that seems to be something else

[04:57:34.0000] <beverloo>
yeah, I found that as well, but that predates the API :)

[04:57:39.0000] <beverloo>
I'll file one later today

[04:57:43.0000] <annevk>
JakeA: each global has its own ServiceWorker instance

[04:58:21.0000] <annevk>
JakeA: and each SW has Client instances

[04:58:41.0000] <annevk>
JakeA: that seems alright to me

[05:00:04.0000] <annevk>
JakeA: but I can see how you don't want to to use Client instances as the other side...

[05:01:07.0000] <annevk>
JakeA: though then you'd need to branch in the onmessage handler on the SW side which doesn't seem great either

[05:01:08.0000] <annevk>
meh

[05:01:12.0000] <annevk>
beverloo: ta

[05:42:16.0000] <jgraham>
Have we considered speccing web components by reality TV show? We lock all the participants in a house with some cameras and every week the public get to vote off whoever isn't providing something useful. At the end of it we either have a spec or everyone involved has killed each other.

[05:43:05.0000] <annevk>
jgraham: that's your idea of better than the status quo?

[05:43:22.0000] <bkardell>
/me lol annevk

[05:43:41.0000] <jgraham>
annevk: It seems like you have much better incentives than in the status quo

[05:44:00.0000] <jgraham>
If you don't do useful things you get voted off and so your opinion is discounted

[05:44:08.0000] <annevk>
Depends, would there be memes? https://twitter.com/w3cmemes

[05:44:23.0000] <jgraham>
Also it would provide W3C with a revenue source so they can stop offering jQuery training

[05:46:16.0000] <jgraham>
I'm sure there would be memes

[05:51:43.0000] <bkardell>
You know what actually could be intersting - public debates

[05:52:36.0000] <bkardell>
debate style... moderator, make your case, video stream

[05:53:02.0000] <bkardell>
I'd watch - I bet I could get a lot of people to watch and comment

[06:36:52.0000] <annevk>
I don't think that will lead to an inclusive design

[06:37:02.0000] <annevk>
Though I guess it might be entertaining

[07:10:16.0000] <wanderview>
JakeA: do you have any sense about how often devs will want to use Cache prefix matching?  from chrome telemetry or just talking to folks?

[07:26:16.0000] <gsnedders>
/me wonders what the "Other Data" in the Firefox import is

[07:26:22.0000] <gsnedders>
That's some nice clear UI.

[07:28:46.0000] <JakeA>
wanderview: unfortunately it's mostly from my head. I was making sure we had something similar to appcache's FALLBACK matching

[07:29:36.0000] <JakeA>
wanderview: if there's an implementation concern around it, I'm open to removing it. It's the least important of the match filters

[07:29:53.0000] <JakeA>
(I think query string ignoring is pretty important)

[07:30:08.0000] <wanderview>
JakeA: its not a concern per-se... I already have it implemented... but its likely I will optimize non-prefix-matching at the expense of making prefix-matching even slower

[07:31:06.0000] <wanderview>
JakeA: it comes down to the sqlite schema... the URL text column can be quite large to begin with and using an index on the column essentially duplicates the data on disk again

[07:57:40.0000] <JonathanNeal>
What if [hidden] accepted a list of media types? I need something like [hidden="screen"] to describe stuff I want hidden from the screen but perceivable to screenreaders.

[08:08:02.0000] <JakeA>
wanderview: at the moment we have lots of engineers visiting London, which includes the people working on our cache impl. They also see prefix-matching as a deopt. Let's get rid of it! We can always add it back later.

[08:08:32.0000] <wanderview>
JakeA: actually I need it for a side project I'm working on :-)

[08:09:00.0000] <wanderview>
but I guess I could skin that cat a different way

[08:09:02.0000] <JakeA>
wanderview: ohhh interesting. What's the use-case? Is it tough to do without the filter?

[08:14:13.0000] <wanderview>
JakeA: sent you a private message

[08:47:01.0000] <JakeA>
annevk: yeah, can't use client.onmessage for client-to-sw messages due to SW termination

[08:48:01.0000] <JakeA>
stashing ports in SW gives us a way to recreate the SharedWorker style of messaging, but ugh

[08:48:30.0000] <JakeA>
and also GC observation, potential leaks, and also ugh

[08:55:56.0000] <annevk>
JakeA: well you could, if all clients are always available

[08:56:07.0000] <annevk>
JakeA: you'd synchronously register onmessage handlers at the start

[08:56:19.0000] <annevk>
but it's rather sad

[08:58:12.0000] <JakeA>
Could hand-wave it to a "clientmessage" global event. But that that point it may as well be onmessage. Hmm.

[08:59:16.0000] <annevk>
So the annoying thing is that everywhere else the message event protocol avoids branching inside the handler

[08:59:44.0000] <annevk>
Do service workers already use self.onmessage for something?

[09:00:03.0000] <annevk>
I wouldn't mind clientmessage to signify its uniqueness, but hmm

[09:00:26.0000] <JakeA>
annevk: serviceWorker.postMessage ends up there

[09:00:39.0000] <annevk>
I gotta go, will have more time during the weekend and beyond

[09:00:42.0000] <JakeA>
That part is similar to dedicated workers

[09:00:43.0000] <annevk>
Well yes, currently

[09:00:52.0000] <JakeA>
have a good weekend!

[09:01:42.0000] <JakeA>
I have a deskbeer so I'm completely useless now

[09:09:16.0000] <annevk>
you too, but sounds like you started already :-)

[12:06:02.0000] <dglazkov>
is there something better than lists.w3.org and less smarmy-adsy than Nabble to link to public-webapps discussions?

[12:07:47.0000] <bkardell>
annevk: you here?

[12:08:10.0000] <Domenic>
dglazkov: readable-email.org was trying for a while but seems to have not kept up with recent messages :(

[12:08:30.0000] <Domenic>
dglazkov: oh it seems to have caught up since last I saw it hmm

[12:08:30.0000] <dglazkov>
that was the best :(

[12:08:34.0000] <dglazkov>
oh?

[12:09:11.0000] <dglazkov>
whoa

[12:11:02.0000] <tantek>
dglazkov - why not post such "emails" on your own site, and only a copy to mailing lists?

[12:11:45.0000] <dglazkov>
tantek: trying to do the other way around -- excavate old email threads

[12:18:44.0000] <bkardell>
does it worry anyone that we're shipping prollyfills as prollyfills before they are out of flags or we even have good signals from all the browsers?

[12:18:56.0000] <bkardell>
arg... shipping prollyfills as polyfills

[12:19:19.0000] <bkardell>
shouldn't we be more careful about that? otherwise, what's the point in dev'ing them outside a flag?

[12:21:51.0000] <smaug____>
bkardell: well, who is shipping

[12:23:37.0000] <bkardell>
smaug___: when I say "we" I mean anyone :)  Is it a bad idea

[12:23:53.0000] <smaug____>
and what do you actually mean. If prollyfill ends up implementing something which never get then implemented after all, users can still use that prollyfill, right?

[12:24:10.0000] <smaug____>
and then it is just a script library exposing random API not implemented anywhere

[12:24:21.0000] <bkardell>
smaug___: yes! the problem is what if it doesn't match

[12:24:27.0000] <smaug____>
s/implemented/implemented natively/

[12:24:39.0000] <bkardell>
this is a pattern that needs advice/discussion imo

[12:24:51.0000] <bkardell>
https://github.com/github/fetch for example - I'm seeing a hella lot of people using that

[12:25:31.0000] <smaug____>
ah, and then implementations will do something a bit different, and the prollyfill implementation is behind the native implementations ?

[12:25:32.0000] <bkardell>
but I dont know that we've had any signals from ms or apple at all - say for example - a change is necessary somewhere

[12:25:47.0000] <smaug____>
right

[12:25:49.0000] <bkardell>
yes, basically we've seen this happen a buncha times

[12:25:56.0000] <bkardell>
array contains?

[12:26:07.0000] <bkardell>
same deal

[12:26:24.0000] <smaug____>
it would be indeed interesting to hear more feedback from MS and Apple to ServiceWorkers

[12:26:32.0000] <bkardell>
in the case of fetch promises are kinda done deal, so why not just ._fetch()

[12:26:56.0000] <bkardell>
if it works for you today it will work for you tomorrow - probably better since browsers tend to get better

[12:27:03.0000] <bkardell>
if you get lucky, remove the _

[12:27:09.0000] <bkardell>
or alias it with native

[12:27:37.0000] <bkardell>
was thinking of sending that feedback, esp since it is now listed on ft labs polyfill service

[12:27:57.0000] <bkardell>
I think that is sending mixed messages and creating an issue that is easily avoided

[12:28:06.0000] <bkardell>
am I making too much of nothing?

[12:28:38.0000] <tantek>
bkardell: what's the worst that could happen? storage? appcache?

[12:29:04.0000] <bkardell>
tantek: how is appcache related?

[12:29:27.0000] <tantek>
just a couple of problematic APIs off the top of my head

[12:29:34.0000] <tantek>
*local storage

[12:29:34.0000] <bkardell>
ah

[12:29:38.0000] <smaug____>
storage and appcache were both real things

[12:29:46.0000] <bkardell>
no I am thinking more like Array.prototype.contains

[12:29:48.0000] <smaug____>
which the later were noticed to be rather bad ones

[12:29:52.0000] <smaug____>
then

[12:30:05.0000] <bkardell>
ES had to change it at the last minute because you can't - you'll break web stuff

[12:30:20.0000] <tantek>
bkardell: then could prollyfills help avoid the "later noticed" problem and notice sooner when APIs are bad?

[12:30:37.0000] <bkardell>
tantek: sure, you could - that's part of the idea

[12:31:11.0000] <bkardell>
tantek: like, we put native implementations behind a flag - we used to prefix them - to tell people "these are experimental"

[12:31:20.0000] <bkardell>
but we found that that is a footgun

[12:31:31.0000] <bkardell>
a prollyfill is a way to stride the chasm

[12:31:39.0000] <smaug____>
I guess it is mainly about when one can think some API is "stable"

[12:31:44.0000] <smaug____>
and that depends on who to ask

[12:32:08.0000] <bkardell>
yeah, and it's kinda what I'm saying... it's about managing risk and I dont know how risky it is in this particular case

[12:32:31.0000] <tantek>
smaug____: clearly "stable" != good

[12:32:33.0000] <bkardell>
I do know though that there's no signals at all from apple and ms has, according to chrome status, given mixed signals

[12:32:35.0000] <tantek>
or not necessarily

[12:32:57.0000] <smaug____>
tantek: indeed, but stable is usually something browsers ends up shipping

[12:33:02.0000] <smaug____>
we haven't removed that many APIs

[12:33:05.0000] <bkardell>
but especially in this case, it seems easy to avoid the worst risk

[12:33:15.0000] <bkardell>
by just saying underscore the prollyfill

[12:33:42.0000] <bkardell>
since it's api has no complex intertwined dependencies, it's basically one method

[12:34:34.0000] <bkardell>
so... is it crazy to suggest that? am I tilting at windmills needlessly?

[12:37:32.0000] <bkardell>
it feels like so close to really good  - if it goes wrong, that will be sad

[12:38:16.0000] <JonathanNeal>
bkardell: what about ft polyfill? =)

[12:38:26.0000] <bkardell>
good! you are on!

[12:38:30.0000] <bkardell>
read above

[12:39:20.0000] <JonathanNeal>
i did, but i didn’t follow the conversation.

[12:39:39.0000] <bkardell>
starting http://krijnhoetmer.nl/irc-logs/whatwg/20150206#l-592

[12:40:31.0000] <bkardell>
is it still unclear?

[12:40:44.0000] <JonathanNeal>
Yea, polyfill is pretty aggressive, but unlike browsers, users can stick to one version of an api.

[12:41:06.0000] <bkardell>
they can until there is a true version which claims to be the same version

[12:41:09.0000] <bkardell>
right?

[12:41:14.0000] <JonathanNeal>
It would be like if you could ‘use strict 1.5.2’; in js.

[12:41:16.0000] <bkardell>
that will present a problem

[12:41:54.0000] <bkardell>
say the draft today says the api should look like foo(x, y)

[12:42:04.0000] <JonathanNeal>
Yea … you are touching on something I wanted to see, which is levels of polyfill compliance.

[12:42:26.0000] <bkardell>
well, this is pretty simple to avoid - just use ._fetch

[12:42:54.0000] <JonathanNeal>
You’re not really using a polyfill as a polyfill then.

[12:43:04.0000] <bkardell>
I'm suggesting simply we dont claim to be the real thing until we can say for sure what the real thing is

[12:43:09.0000] <bkardell>
it's not a polyfill

[12:43:12.0000] <bkardell>
its a prollyfill

[12:43:37.0000] <bkardell>
the lack of distinction is the part that worries me

[12:43:38.0000] <JonathanNeal>
bkardell: we never claim, we wait for a spec, and the only difference between a prollyfill and a polyfill is an implementation not behind a flag.

[12:44:23.0000] <JonathanNeal>
i know because i usually write prollyfills before a spec exists, but I’ve protected myself from allowing them into the project until I see a spec. .closest was a good example.

[12:44:37.0000] <bkardell>
you're misreading my point, I'm not saying you claim as in you state it in words

[12:45:06.0000] <JonathanNeal>
You mean, we treat prollyfills and polyfills the same, and people are probably leveraging prollyfills (instead of just polyfills) more and more?

[12:45:45.0000] <bkardell>
JonathanNeal: no, that's a good thing - it's what I want... I just want them to do it safely.  Appearance in a spec definitely does not mean that that is what we will get

[12:45:48.0000] <JonathanNeal>
And that’s dangerous if the functionality changes between the prollyfill and the real thing?

[12:45:53.0000] <bkardell>
yes!

[12:46:24.0000] <bkardell>
not just dangerous in code though - browsers and standards care

[12:46:27.0000] <JonathanNeal>
Yea. The problem with prefixing apis is that people never unprefix them.

[12:46:52.0000] <bkardell>
doesn't matter if you unprefix fetch or not in this case, does it?

[12:47:26.0000] <JonathanNeal>
Unless every api some kind of .spec or .lastUpdated key we could reference to know whether or not we should use native functionality.

[12:47:39.0000] <bkardell>
if you were so lucky as to have it match then you could simply say _fetch = fetch; and be done

[12:47:57.0000] <JonathanNeal>
Alternatively, I see people doing very complex tests before a polyfills to determine if the polyfill should deploy.

[12:48:30.0000] <bkardell>
I dont understand why that matters tho... that's about browsers prefixing which they have basically agreed to stop doing and put behind a flag for basically this reason

[12:49:02.0000] <JonathanNeal>
Yea, but when the functionality is really desired, the moment it appears in a spec, we’re gonna get an issue filed to include it.

[12:49:04.0000] <bkardell>
if you write code that uses an experimental thing, but you also provide the experimental implementation (prollyfill) you can go about your day - job done

[12:49:17.0000] <bkardell>
so include it, I love that!

[12:49:22.0000] <JonathanNeal>
Same for when something changes, it’s within hours.

[12:49:33.0000] <bkardell>
just asking that we do _fetch or something instead of .fetch

[12:49:39.0000] <bkardell>
at least until we're pretty sure

[12:49:41.0000] <JonathanNeal>
yea but what if the name changes.

[12:49:49.0000] <bkardell>
what name changes?

[12:49:55.0000] <JonathanNeal>
_fetch becomes _get or something

[12:49:59.0000] <bkardell>
do you want to take this privately or is anyone else interested?

[12:50:09.0000] <JonathanNeal>
_has becomes _contains, etc.

[12:50:33.0000] <JonathanNeal>
I don’t have a solution, but I think the problem you are describing is a big web question.

[12:50:33.0000] <lerc>
Did the canvas on worker porposal go anywhere?   https://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0199.html

[12:51:16.0000] <JonathanNeal>
In a world with evergreen browsers, who’s going to wait for native functionality anymore?

[13:03:17.0000] <Domenic>
People who don't want to wait for stuff to go through standardization before using it

[13:03:30.0000] <Domenic>
i.e., the "why can't I track steps using a web app" problem

[13:10:49.0000] <bkardell>
Domenic: Are you under the impression that that is what I am suggesting in some way?

[13:11:01.0000] <Domenic>
bkardell: nope, just responding to JonathanNeal's perspective.

[13:11:07.0000] <Domenic>
s/perspective/question

[13:15:51.0000] <bkardell>
Domenic: Yeah, that would have suprised me :)


2015-02-07
[23:03:24.0000] <jwalden>
/me lols a bit at some of the web components thread linked from w3cmemes

[08:24:37.0000] <annevk>
lerc: https://wiki.whatwg.org/wiki/WorkerCanvas2 was recently posted


2015-02-08
[19:08:06.0000] <SimonSapin>
MikeSmith: Can we get HTTPS on dev.w3.org?

[19:17:00.0000] <MikeSmith>
SimonSapin: I'd rather we just quit using dev.w3.org altogether

[19:17:43.0000] <MikeSmith>
SimonSapin: all dev.w3.org URL for CSS WG specs are just rewrites to csswg.org

[19:18:12.0000] <MikeSmith>
drafts.csswg.org

[19:46:51.0000] <SimonSapin>
MikeSmith: don’t break URLs :(

[19:47:19.0000] <SimonSapin>
MikeSmith: could they be 301 redirects instead?

[19:51:24.0000] <MikeSmith>
SimonSapin: yeah definitely they could be

[19:51:42.0000] <MikeSmith>
I'd personally prefer they were

[19:51:51.0000] <MikeSmith>
but they're the way they are because Peter Linss asked me to be set them up exactly the way they are

[19:52:29.0000] <SimonSapin>
ok, thanks

[00:23:46.0000] <annevk>
SimonSapin: http://mirror.csclub.uwaterloo.ca/csclub/speed-is-hard-at-uwaterloo.pdf is super interesting


2015-02-09
[21:53:46.0000] <zcorpan>
mathiasbynens: did you have a script to normalize scrollTop for html/body without browser sniffing?

[21:58:44.0000] <matijs>
zcorpan: did you mean https://gist.github.com/dperini/ac3d921d6a08f10fd10e ?

[22:00:11.0000] <zcorpan>
matijs: looks like what i wanted at least. thanks

[22:57:11.0000] <estellevw__>
i thought input type=“datetime” was pulled from the spec, but I see it here: https://html.spec.whatwg.org/multipage/forms.html#date-and-time-state-(type=datetime).

[22:58:19.0000] <mathiasbynens>
zcorpan: https://github.com/mathiasbynens/jquery-smooth-scrolling/blob/fba27f86a6b3a8788d1c1b3aa94a951eb9f087dc/jquery.smoothscroll.js#L4-L21 (jQuery but you get the idea)

[22:58:47.0000] <mathiasbynens>
matijs: wow, dperini’s is much nicer

[22:58:56.0000] <estellevw__>
I thought it was removed over a year ago. anyone know the status?

[23:00:25.0000] <mathiasbynens>
difference: mine is an actual feature test; dperini’s is based on weak inference

[23:00:38.0000] <zcorpan>
matijs: mathiasbynens: https://github.com/operasoftware/devopera/issues/242

[23:59:04.0000] <annevk>
estellevw__: in favor of only having datetime-local?

[23:59:30.0000] <annevk>
/me can't find a bug that has datetime in the description

[00:04:18.0000] <estellevw__>
I can only find discussions on “non-official” sites that it has been dropped, and browsers don’t support it, but don’t know if WHATWG is or has actively discussed it

[00:28:38.0000] <annevk>
estellevw__: there has been mailing list discussion about the merits of datetime vs datatime-local

[00:28:52.0000] <annevk>
estellevw__: and that ideally datetime-local would've been named datetime

[00:29:04.0000] <annevk>
have been*

[00:30:14.0000] <estellevw__>
annevk: I believe that was over a year ago. Not sure what the process is for removing stuff from the spec. Trying to determine if it’s a done deal, or it is still being considered.

[00:37:32.0000] <annevk>
estellevw__: https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F

[00:37:42.0000] <MikeSmith>
estellevw__: https://lists.w3.org/Archives/Public/public-html/2014Feb/0003.html

[00:37:53.0000] <estellevw__>
thanks.

[00:38:00.0000] <estellevw__>
haha, yes, exactly a year ago.

[00:38:18.0000] <MikeSmith>
and https://www.w3.org/Bugs/Public/show_bug.cgi?id=16959

[00:39:17.0000] <MikeSmith>
and https://www.w3.org/Bugs/Public/show_bug.cgi?id=17855

[00:39:25.0000] <annevk>
"It was noted that at the F2F that this feature is at risk for 5.0." and it was never resolved?

[00:40:31.0000] <annevk>
MikeSmith: that latter bug seems mostly about terminology, not about changing controls

[00:40:46.0000] <MikeSmith>
right, it's a different issue

[00:41:04.0000] <MikeSmith>
...I realize now

[00:41:12.0000] <MikeSmith>
/me hunts some more

[00:42:08.0000] <MikeSmith>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16960 is the one I was trying to find, I think

[00:42:32.0000] <MikeSmith>
corresponding whatwg bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=17856

[00:43:22.0000] <MikeSmith>
christ

[00:43:24.0000] <annevk>
Which defers to a mailing list thread :-)

[00:43:38.0000] <MikeSmith>
yeah not sure that's it either

[00:43:41.0000] <MikeSmith>
too many bugs

[00:43:50.0000] <MikeSmith>
https://github.com/w3c/html/commit/3e5df1ee1aebed37571a23c9b62adc74a92a04b9

[00:43:51.0000] <estellevw__>
month and week are also both in the living standards and 5.1 but not in 5.0, but i see no discussion on those being at risk

[00:43:58.0000] <MikeSmith>
Removing input type="datetime-local"

[00:44:16.0000] <annevk>
https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0367.html and onwards

[00:44:46.0000] <annevk>
Wait they removed the useful one?

[00:44:46.0000] <estellevw__>
hmm, browsers have implement datetime-local but not datetime

[00:44:53.0000] <annevk>
lol

[00:45:00.0000] <annevk>
Typical committee decision

[00:45:56.0000] <MikeSmith>
estellevw__: https://github.com/w3c/html/commit/6ef6eaaad792247c89b2e231e9100d5ff413ad90 "removed input types datetime, datetime-local, week, month"

[00:46:08.0000] <estellevw__>
thanks.

[00:46:25.0000] <estellevw__>
https://miketaylr.com/code/input-type-attr.html shows datetime is NOT supported, but datetime-local is

[00:47:15.0000] <estellevw__>
in blink

[00:48:12.0000] <MikeSmith>
I think I may have actually been the one who recommended that we drop datetime, datetime-local, week, month from the W3C spec at that time

[00:48:23.0000] <MikeSmith>
I don't remember

[00:48:49.0000] <MikeSmith>
maybe darobin will remember better than me, if you want to ask him once he's around

[00:50:16.0000] <estellevw__>
will do. Thanks. My thought is some of those may have been dropped from 5 and left in 5.1 because they still needed to be better flushed out, like ::selection in CSS being moved from the selectors spec so that the spec can move forward.

[00:50:49.0000] <estellevw__>
Would like to know if I assuming incorrectly thought

[00:50:51.0000] <estellevw__>
thanks.

[00:59:16.0000] <MikeSmith>
estellevw__: I suggest telling your readers to consider the W3C HTML5 Rec just be a snapshot of a subset of what the state of HTML was in October 2014

[01:00:50.0000] <MikeSmith>
I think it'd be misleading to lead them to believe they can work from the HTML5 Rec alone as a guide when authoring documents

[01:01:23.0000] <MikeSmith>
for one thing, even the W3C validator doesn't restrict itself to only what's included in the HTML5 Rec

[01:02:03.0000] <MikeSmith>
e.g., the validator still considers datetime, datetime-local, week, month to be valid

[01:03:44.0000] <MikeSmith>
and there was never any decision in the HTML WG to drop them from HTML5 itself. Instead there was just an editorial decision to leave them out of the HTML5 Rec snapshot.

[01:05:05.0000] <MikeSmith>
as one of the main people responsible for creating all that confusion, I'd be happy to try to help come up with some wording that would hopefully make it all less confusing for readers

[01:07:12.0000] <MikeSmith>
estellevw__: I think http://www.w3.org/html/landscape/ is a still a good document to refer to for clarification about what the differences are, and a good document to point readers to

[01:07:31.0000] <MikeSmith>
although I realize it's also not complete

[01:08:08.0000] <MikeSmith>
hmm I think it's closer than I realized though

[01:08:26.0000] <MikeSmith>
e.g.,:

[01:08:27.0000] <MikeSmith>
No input types datetime, datetime-local, week, month in W3C HTML 5.0 (user agent)

[01:08:31.0000] <MikeSmith>
Insufficient implementation experience at this point.

[01:08:46.0000] <MikeSmith>
... is listed there

[01:08:55.0000] <MikeSmith>
"Insufficient implementation experience at this point."

[01:09:29.0000] <MikeSmith>
I think Robin did a great job at putting that together

[07:12:28.0000] <JonathanNeal>
https://dom.spec.whatwg.org/#mutation-method-macro — could this macro ever be exposed as a public method? Would there be a proper name or place for this macro, like ParentNode.mutation?

[07:18:24.0000] <annevk>
JonathanNeal: not sure we should expose that

[07:18:40.0000] <annevk>
TabAtkins: any update on bikeshedding DOM?

[07:31:02.0000] <JonathanNeal>
annevk: We have a set of DOM polyfills that rely on the mutation macro. Inspired by the change from ParentNode.replace to ParentNode.replaceWith, we plan to separate each of the polyfills and let them reference a separate mutation method. Keeping that method private is not a problem, but I want the name to be a semantic as possible. So, I’m trying to

[07:31:02.0000] <JonathanNeal>
imagine what its name might be were the method public.

[07:42:01.0000] <annevk>
JonathanNeal: I would imagine it to be a symbol if it were public

[07:47:34.0000] <caitp>
they might need to target super-legacy browsers with no concept of symbols, though

[07:49:06.0000] <JonathanNeal>
annevk, caitp: indeed.

[07:49:59.0000] <annevk>
JonathanNeal: if you keep it private it doesn't seem to matter much

[07:50:09.0000] <annevk>
JonathanNeal: mutationMacro and just rename it if the DOM changes?

[07:50:36.0000] <annevk>
JonathanNeal: mutaitonMacro might not be super semantic either, all it's doing is pre-processing the arguments passed

[07:53:39.0000] <safinaskar>
is living html turing complete?

[07:54:29.0000] <annevk>
safinaskar: HTML's parser is, yes, due to </script>

[07:55:37.0000] <safinaskar>
annevk: you mean js?

[08:09:47.0000] <safinaskar>
okey, what is we disallow inclusion of other languages? is html turing complete?

[08:16:18.0000] <safinaskar>
:(

[08:21:01.0000] <caitp>
i mean

[08:21:33.0000] <caitp>
if you don't include document.write

[08:21:42.0000] <caitp>
i'm not sure you could call html turing complete

[08:23:00.0000] <jgraham>
Hmm, how does </script> make the parser turing complete?

[08:23:02.0000] <caitp>
maybe with html imports you could theoretically create some kind of turing complete program using imports for flow control

[08:23:33.0000] <caitp>
but you wouldn't really have any other flow control operators, I guess?

[08:23:35.0000] <jgraham>
Yeah, I'm struggling to see how HTML could be turing complete without imports

[08:25:16.0000] <jgraham>
(I'm not convinced it is with imports, but it doesn't seem obviously impossible)

[08:25:44.0000] <jgraham>
Clearly as soon as you can run js, it *is* turning complete

[08:25:49.0000] <jgraham>
*Turing

[08:26:37.0000] <caitp>
i think that's what the script tag thing was all about

[08:27:08.0000] <caitp>
you could write a programme with just <script>document.write()</script>

[08:27:52.0000] <caitp>
it might not be a very useful programme, but hey

[08:30:24.0000] <albinowax>
I think CSS comes close

[08:36:43.0000] <JonathanNeal>
the problem with prollyfills is catching up with us: https://github.com/Financial-Times/polyfill-service/issues/284

[08:36:56.0000] <caitp>
http://jsbin.com/cuzatanufa/1/edit?html,output well that was pretty much the best i could come up with

[08:37:01.0000] <caitp>
I didn't know document.write limited recursion

[08:37:05.0000] <caitp>
apparently it does

[08:39:06.0000] <Domenic>
JonathanNeal: seems like your bad for not following semver

[08:39:29.0000] <Domenic>
JonathanNeal: or rather, financial times's bad

[08:48:19.0000] <JonathanNeal>
Domenic: I forwarded the recommendation. Thanks for raising the macrotask/microtask issue as well.

[08:49:00.0000] <annevk>
https://twitter.com/mulambda/status/564824426756472832 \o/

[08:49:16.0000] <JonathanNeal>
It relates to a need we have for private methods, such as mutationMacro and whatever-handles-microtasks.

[10:11:52.0000] <wanderview>
JakeA: I seem to recall a github issue where we were talking about if Cache.add() or Cache.put() would continue even after the SW shuts down... maybe for background sync type stuff... do you remember that?  I can't find the issue

[10:12:57.0000] <wanderview>
JakeA: I just wanted to note that we're probably going to cancel network requests when the SW exits (although we will probably try to keep the SW alive until all the network requests are complete)

[11:28:30.0000] <JonathanNeal>
Is there any way to simulate the ParentNode object? It equates Document, DocumentFragment, and Element.

[11:29:32.0000] <caitp>
what do you mean by simulate it

[11:33:09.0000] <Domenic>
[Document, DocumentFragment, Element].forEach(...)

[11:34:59.0000] <jsbell>
JonathanNeal: polyfilling the newish DOM functions? https://github.com/inexorabletash/polyfill/blob/master/experimental/dom.js

[11:37:11.0000] <JonathanNeal>
They were polyfilled long ago, but I’m trying to improve upon then. I want to make each polyfill modular so changing replace with replaceWith doesn’t affect the other methods. It’s also nicer when Chrome requires less methods than all other browsers.

[11:37:19.0000] <JonathanNeal>
^ jsbell

[11:37:45.0000] <JonathanNeal>
Domenic, ok, might as well Document.prototype.thing = DocumentFragment.prototype.thing = Element.prototype.thing then

[11:38:22.0000] <Domenic>
JonathanNeal: no, that wouldn't be spec compliant, they shouldn't be ===

[11:40:14.0000] <caitp>
as soon as time machines capable of travelling backwards are a thing, someone is going to fix DOM

[11:40:22.0000] <JonathanNeal>
Domenic: really? Even though they’re all ParentNode?

[11:40:49.0000] <caitp>
probably not before that, though

[11:49:03.0000] <Domenic>
JonathanNeal: yes

[11:50:26.0000] <JonathanNeal>
That is wild. Cause, like, HTMLElement.prototype.remove === Element.prototype.remove

[11:51:55.0000] <caitp>
but not Document.prototype.remove or DocumentFragment.prototype.remove

[11:52:17.0000] <JonathanNeal>
Wild.

[11:52:43.0000] <JonathanNeal>
What is the reason the inheritency doesn’t cross between Document and Element?

[11:53:12.0000] <caitp>
element does not extend document or vice versa, they're different node types

[11:53:37.0000] <JonathanNeal>
So that, in theory, ParentNode.prototype.remove === Element.prototype.remove && ParentNode.prototype.remove === Document.prototype.remove && Document.prototype.remove !== Element.prototype.remove

[11:54:29.0000] <caitp>
well ParentNode isn't a real thing, it's like a macro, its definition gets copied into the interfaces that implement it

[11:54:36.0000] <caitp>
so when you look at it that way it makes sense

[11:55:07.0000] <caitp>
it's dumb, but it makes sense

[11:55:23.0000] <JonathanNeal>
Thanks, caitp. It is dumb, but I’ll do my best to follow it.

[12:02:09.0000] <JonathanNeal>
Unrelated. What is the name of the thing that cues microtasks in JavaScript? It’s used by MutationObserver and Promise.

[12:02:56.0000] <JonathanNeal>
In Node, it’s process.nextTick.

[12:05:10.0000] <jsbell>
JonathanNeal: There's no standardized entry point from script

[12:06:02.0000] <jsbell>
Some Promise polyfills used MutationObserver :P

[12:08:21.0000] <JonathanNeal>
Yea. I’m creating a private method to handle microtasks, but I don’t even know what the method or macro or whatever-it-is is called. I might just call it nextTick and use it like nextTick(callback).

[12:09:22.0000] <Domenic>
it's called enqueueMicrotask

[12:10:15.0000] <JonathanNeal>
Domenic++ yeaaaaa

[12:10:37.0000] <Domenic>
there's been some attempt at making "asap" the slang name. Hasn't caught on that much.

[12:15:20.0000] <hober>
nowish()

[12:15:28.0000] <hober>
rsn()

[12:18:38.0000] <JonathanNeal>
Is enqueueMicrotask a private method or a macro or what?

[12:20:37.0000] <Domenic>
it's a spec-level "abstract operation"

[12:20:45.0000] <Domenic>
although HTML doesn't call them that or use function-call notation

[12:21:08.0000] <Domenic>
It's certainly not a method of anything

[12:26:10.0000] <JonathanNeal>
Domenic: for the purpose of polyfills, it would be best experienced as a method. Thanks, I’ve applied your feedback to my recommendation in FT’s polyfill-service.

[12:26:28.0000] <Domenic>
JonathanNeal: what object is your polyfill making it a method on?

[12:28:01.0000] <annevk>
JonathanNeal: what is dump about a mixin?

[12:28:13.0000] <annevk>
JonathanNeal: if you think we should do something else, please do file a bug

[12:28:30.0000] <JonathanNeal>
annevk: dump about a mixin? I don’t follow.

[12:29:51.0000] <annevk>
JonathanNeal: above you called the ParentNode design dumb

[12:30:44.0000] <caitp>
technically, I called it dumb, and it is --- it's like half-baked trait support without being built on a feature of the language

[12:30:58.0000] <caitp>
it's not really exposed to the language, so you just have to know a bunch of arbitrary crap to deal with it

[12:31:12.0000] <caitp>
which is objectively terrible, I mean come on, this isn't news to anybody

[12:31:45.0000] <caitp>
but you know that filing a bug on it wouldn't be actionable

[12:31:48.0000] <caitp>
none of this can ever really change

[12:31:52.0000] <caitp>
so, it's just the way it is

[12:33:02.0000] <annevk>
There's no native support and the IDL looks a bit clunky, but copying over prototypes is done by JavaScript itself and seems perfectly decent

[12:33:28.0000] <annevk>
So, I guess I disagree

[12:33:33.0000] <caitp>
here's the thing

[12:33:45.0000] <caitp>
suppose your api needs to deal with anything implementing this trait, what do you do?

[12:33:49.0000] <Domenic>
Yeah, I think objectively terrible is a strong overstatement

[12:33:51.0000] <caitp>
you're looking at node types, or the constructor property

[12:33:55.0000] <caitp>
or instanceof

[12:34:16.0000] <caitp>
and this means you're dealing with things that don't really matter

[12:34:48.0000] <caitp>
best case would be if (!this implements Trait) throw TypeError();

[12:34:49.0000] <caitp>
or something

[12:35:19.0000] <caitp>
but instead you have to dig up idl and figure out everything that implements the trait, and how to identify those things

[12:35:58.0000] <caitp>
that's all kind of awful, like it's not a good scene, it's just that everyone has been stuck with it for so long that it will probably never become not-bad

[12:37:24.0000] <annevk>
caitp: it's not a trait, it's a mixin

[12:37:36.0000] <caitp>
it's basically a trait

[12:37:44.0000] <caitp>
it would be better if it were a trait

[12:37:44.0000] <JonathanNeal>
annevk: i concurred with caitp that it is dumb — but what more can I do but sigh? If it already works this way, “fixing” it would involve changing aka breaking the way it worked before, so would filing a bug be anything more than futile?

[12:37:48.0000] <annevk>
well you can keep calling it that, but I don't think there's anything that supports that

[12:38:08.0000] <caitp>
the only difference between a trait and a mixin, is that you can tell if something implements a trait

[12:38:15.0000] <annevk>
sure

[12:38:37.0000] <caitp>
which is simpler, and more scalable

[12:38:42.0000] <annevk>
IDL does not have traits, just mixins

[12:38:44.0000] <caitp>
thus objectively better and more correct

[12:39:28.0000] <annevk>
I don't really see how it would be simpler

[12:40:00.0000] <annevk>
JonathanNeal: I don't think much of this is implemented so dunno

[12:40:03.0000] <caitp>
traits -> you have a single thing that you need to be aware of: "does X implement T or not"

[12:40:17.0000] <caitp>
mixins -> you have N things you need to be aware of

[12:40:28.0000] <JonathanNeal>
Domenic: re: what object is your polyfill making it a method on? No object, it would be a private method within a closure, exposed only to polyfills.

[12:40:42.0000] <Domenic>
JonathanNeal: all methods are on objects... do you mean it's a function then?

[12:41:10.0000] <caitp>
1 is fewer than N, thus mixins are simpler

[12:41:24.0000] <JonathanNeal>
As in all var’d and function’d things? Yes.

[12:41:35.0000] <caitp>
er

[12:41:36.0000] <caitp>
traits are

[12:41:45.0000] <caitp>
I totally got that ass-backwards in that last line :>

[12:42:16.0000] <annevk>
I think in this case mixins are simpler since all these methods delegate to generics anyway

[12:42:36.0000] <annevk>
If we designed things from the ground up it might be different of course

[12:42:36.0000] <JonathanNeal>
Domenic: the living example would be https://github.com/Financial-Times/polyfill-service/blob/feature/enqueueMicrotask/polyfills/enqueueMicrotask/polyfill.MutationObserver.js

[12:42:52.0000] <Domenic>
JonathanNeal: yeah, that's definitely not a method.

[12:42:55.0000] <annevk>
Well, not might, if we did it today things definitely would be a lot different :-)

[12:43:29.0000] <caitp>
well, it's possible that we will have traits some day, and webidl could be rewritten to make these partial interfaces traits, and it could still easily be backwards compatible

[12:43:40.0000] <caitp>
but that's just blocked on so many things that it's just as likely to never happen

[12:43:57.0000] <annevk>
I don't see how these particular methods would benefit from being traits

[12:44:15.0000] <annevk>
They're generic, like Array methods

[12:44:39.0000] <caitp>
it's not really about the implementation

[12:44:56.0000] <Domenic>
annevk: that's not quite accurate; array methods don't do brand checks, whereas these do.

[12:44:57.0000] <caitp>
it's about being able to easily identify things that have them, don't have them, or should have them

[12:45:18.0000] <caitp>
if a polyifller just needed to extend a trait, that would be pretty awesome

[12:45:24.0000] <annevk>
Domenic: fair

[12:45:25.0000] <caitp>
typing is hard

[12:46:06.0000] <annevk>
caitp: also fair

[12:46:46.0000] <annevk>
https://github.com/whatwg/streams/commit/06143f8bb8b92381fcce5f1f4f2d6fe10b64d087 Domenic++

[12:47:12.0000] <Domenic>
^_^

[12:47:55.0000] <annevk>
Domenic: have you discussed Streams with sicking lately? Seems he still has the 4 objects vs constructing some kind of pipe concern

[12:48:10.0000] <Domenic>
annevk: we had a bit of a discussion in the bug, I don't think he responded to the point

[12:48:19.0000] <annevk>
ah right

[12:49:20.0000] <Domenic>
This is interesting http://www.do-not-panic.com/2014/02/developer-certificate-of-origin.html more lightweight than a CLA but seemingly just as good

[12:51:39.0000] <annevk>
/me read CA and got confused

[12:52:13.0000] <annevk>
"certificate" and "origin" did not help

[12:52:21.0000] <Domenic>
hahaha

[12:56:30.0000] <Domenic>
more http://lwn.net/Articles/592503/


2015-02-10
[17:18:51.0000] <MikeSmith>
Domenic: I see "Agreement to the DCO is thus transmitted with each patch." but I don't find an actual description of how the agreement is actually recorded/transmitted

[17:19:26.0000] <Domenic>
MikeSmith: it appears to be the "Signed-off-by: Name <email>" lines in a given patch

[17:19:27.0000] <MikeSmith>
ah wait the paragraph just before that

[17:19:47.0000] <Domenic>
I'm a little unclear why asking a developer to include a signed-off-by line would be less onerous than asking them to sign a CLA

[17:20:50.0000] <MikeSmith>
that plus I wonder what happens if they forget to include that line in the commit message

[17:21:11.0000] <MikeSmith>
I guess reviewers are supposed to check for that before they merge anything

[17:22:39.0000] <zcorpan>
MikeSmith: https://github.com/ResponsiveImagesCG/picture-element/issues/256

[17:25:32.0000] <MikeSmith>
zcorpan: yep, saw that you had raised that. I have no strong opinion on it either way. I don't think it would be any harder to implement a check for than any other of the esoteric requirements for srcset+sizes

[17:26:30.0000] <MikeSmith>
zcorpan: we're already at the point with the validator where the requirements have necessitated breaking abstractions in the code in order to implement

[17:27:45.0000] <MikeSmith>
well maybe not necessitated, but at least I couldn't figure out a way to add some things without violating a few

[17:28:34.0000] <MikeSmith>
zcorpan: e.g., this is what the "Require sizes attr when srcset specifies width" check looks like: Require sizes attr when srcset specifies width

[17:28:37.0000] <MikeSmith>
oops

[17:28:41.0000] <MikeSmith>
https://github.com/validator/validator/commit/8a4adc9834eeb8994deefed9948bc063cc79ce93

[17:29:59.0000] <MikeSmith>
all of the datatype checks in the validators are done using singleton instances of the particular classes that do each check

[17:31:29.0000] <zcorpan>
MikeSmith: ok. for the issue i'm leaning towards just changing the grammar to require the default length

[17:35:29.0000] <MikeSmith>
zcorpan: ok. I think that might at least not have the particular issue that the width-required change did.

[17:36:44.0000] <MikeSmith>
zcorpan: part of the thing that complicates implementing these check is the sort of circular dependency between srcset and sizes with regard to width descriptors

[17:37:22.0000] <MikeSmith>
in that the spec says both, "If a source element has a sizes attribute present or an img element has a sizes attribute present, all image candidate strings for that element must have the width descriptor specified." and (now also) "If the srcset attribute has any image candidate strings using a width descriptor, the sizes attribute must also be present, and the value must be a valid source size list.

[17:37:28.0000] <MikeSmith>
Spec bugs: 26537

[17:37:40.0000] <MikeSmith>
oofs

[17:39:03.0000] <zcorpan>
MikeSmith: i am aware of the two-way dependency, i'm not familiar enough with your impl to tell if there's a better way to do it

[17:40:10.0000] <MikeSmith>
zcorpan: yeah was just thinking out loud

[17:41:10.0000] <MikeSmith>
I reckon Henri could figure out a more elegant way for now what's there works fine

[17:42:04.0000] <zcorpan>
ok cool

[19:42:19.0000] <MikeSmith>
Domenic: I guess the DCO/Signed-off-by thing is not meant to be any less onerous for contributors than signing a CLA isーbut I think one advantage is that it obviates any need to have any process for signing the CLA that's separate from the process for creating a patch/PR, and especially that it obviates the need to keep any separate record somewhere of who's signed the CLA

[19:43:01.0000] <MikeSmith>
since the record of agreements is just right there within the change history for the sources

[23:44:21.0000] <MikeSmith>
botie, inform hsivonen when you have a minute please take a look at the following and let me know if you're OK with it. Basically it just refines fatal-error messages for files with content-type mismatches to include mention of the URL for the file. It seems safe to do since it's not leading any info the user doesn't already know. https://github.com/validator/validator/commit/c98215c55d2a8cd433877da23119

[23:44:21.0000] <botie>
will do

[23:44:27.0000] <MikeSmith>
16c9ebbfd342

[23:44:46.0000] <MikeSmith>
botie, inform hsivonen https://github.com/validator/validator/commit/c98215c55d2a8cd433877da2311916c9ebbfd342

[23:44:46.0000] <botie>
will do

[00:15:52.0000] <ineedhelpors>
hey guys

[00:15:57.0000] <ineedhelpors>
in need of advice

[00:19:28.0000] <ineedhelpors>
paying $10 btc if sum1 can help me with a file upload issue

[00:23:29.0000] <annevk>
Hixie: per https://twitter.com/sgalineau/status/564904540906872833 we should probably list instructions for how to unsubscribe

[00:24:55.0000] <caitp->
you should probably make it a 1 or 2 step process

[00:25:27.0000] <caitp->
and easy enough to figure out that nobody needs to dig around to find instructions and follow them

[00:26:41.0000] <annevk>
I suspect it's as easy as putting un in the obvious place of the subscribe address

[00:44:53.0000] <Krinkle>
Are there any plans for a Cookie interface in the DOM? E.g. for setting/getting cookies in a more object-oriented fashion, and removing the need for string parsing as much (ala classList)

[00:45:10.0000] <Ms2ger>
Not afaik

[00:45:58.0000] <annevk>
I think the recommendation is to leave cookies as a network affair to persist some state about the user

[00:46:07.0000] <annevk>
And put actual data either locally or on the server somehow

[00:46:08.0000] <Krinkle>
It seems the latest trend is to write a spec and have browsers implement it, instead of writing a library and poplarising it. I want in :)

[00:46:43.0000] <annevk>
Heh, I think it's always been a bit of both

[00:46:51.0000] <Krinkle>
Yeah, that's what the big apps do (e.g. Google, Wikipedia, ..)

[00:47:08.0000] <Krinkle>
typically only one main cookie, though that's never really true

[00:47:37.0000] <Krinkle>
Not having to parse and construct document.cookie would be nice :)

[00:51:29.0000] <Krinkle>
rhartl/jquery-cookie/issues/349

[00:51:32.0000] <Krinkle>
https://github.com/carhartl/jquery-cookie/issues/349

[00:51:41.0000] <Krinkle>
Cookie.set(), get(), remove()

[00:59:14.0000] <annevk>
Krinkle: if you do want to propose something, remember that anything synchronous is unlikely to fly

[01:01:51.0000] <Krinkle>
annevk: I don't mind either way. I'm happy for it to be async.

[01:03:07.0000] <Krinkle>
Though I'm curious with regards to race conditions

[01:03:35.0000] <Krinkle>
you wouldn't want one thing to set and another thing to check its existence and also start setting the same thing

[01:04:12.0000] <Krinkle>
Though in a good app (or just a simple app?) a single key would be managed by the same code which would thus naturally be aware of it.

[01:04:22.0000] <Krinkle>
Except when in multiple tabs of course.

[01:06:20.0000] <Krinkle>
with Promise and yield this can be abstracted though I suppose

[01:07:12.0000] <Krinkle>
annevk: You reckon it's feasible? I imagine even without the async benefit, the simplified and directer API for the browser would be worth something.

[01:08:11.0000] <Krinkle>
and if we made it a promise (or did you have another async method in mind?) it would be an opportunity to make cookie setting no longer blocking the main UI thread.

[01:11:06.0000] <terinjokes>
Krinkle: it's seems fairly easy to mock a library up to see how it works :)

[01:12:46.0000] <Krinkle>
Any ideas for what would be a logical/sensible location? global Cookie? Cookieset? document.cookieset? The cross-over between document and window is getter better lately, but it still not clear to me which way it's moving.

[01:13:14.0000] <Krinkle>
I guess for cookies, it's fine for it to not be attached to the document object, right?

[01:16:03.0000] <terinjokes>
Krinkle: why not make it a library first?

[01:16:20.0000] <Krinkle>
Sure

[01:22:28.0000] <annevk>
Krinkle: it would have to work in workers if we do something

[01:22:56.0000] <annevk>
Krinkle: it's not clear that people want to do something though; making cookies a network affair has some obvious benefits

[01:23:21.0000] <Krinkle>
annevk: What you do mean by network affair? No longer exposed in JS entirely?

[01:23:45.0000] <annevk>
Krinkle: yeah, what HttpOnly does

[01:23:52.0000] <Krinkle>
Interesting

[01:24:16.0000] <Krinkle>
Yeah, especially lacking a JsOnly option

[01:24:42.0000] <terinjokes>
we use cookies entirely as a token that we're the same session. we'd rather use one of the other storage mechanisms

[01:24:42.0000] <annevk>
well that's indexed DB et al

[01:25:01.0000] <Krinkle>
While most things I see use Storage for local stuff, there's a bunch of stuff out there that uses cookies. But being sent to the server each request for no reason

[01:25:25.0000] <terinjokes>
you can update older code

[01:25:31.0000] <annevk>
Krinkle: we should offer more control over whether cookies are included in a fetch

[01:25:48.0000] <annevk>
Krinkle: but what we have for that is an all-or-nothing flag

[01:26:10.0000] <Krinkle>
Which flag is that?

[01:26:38.0000] <annevk>
withCredentials in XMLHttpRequest, though it's limited to cross-origin fetches

[01:26:51.0000] <annevk>
fetch() has a way to do it same-origin

[01:27:11.0000] <Krinkle>
Ah, yeah

[01:27:16.0000] <Krinkle>
/me was just reading fetch.spec

[03:02:23.0000] <JakeA>
TabAtkins: is there someone/somewhere/something that collects layout use-cases that aren't possible with CSS?

[03:03:50.0000] <astearns>
JakeA: there's this one: https://www.w3.org/dpub/IG/wiki/Pagination_Requirements

[03:06:03.0000] <JakeA>
astearns: yeah, I guess I'm looking for something like that but general

[03:07:45.0000] <astearns>
JakeA: I think it's hard to come up with general layout requirements that mean much - tying things to specific uses helps refine the requirement

[03:08:16.0000] <astearns>
JakeA: one of the big lacks is laying out elements in relation to other elements, but that's too vague to be useful

[03:08:38.0000] <astearns>
JakeA: laying out elements in relation to a page (for instance) helps focus the idea

[03:09:22.0000] <JakeA>
astearns: heh, the issue I have is an element-to-element relation thing

[03:10:23.0000] <astearns>
JakeA: looking for a place to add your issue to, then?

[03:10:57.0000] <JakeA>
astearns: Well, maybe. I probably need to think about it a bit more, but was just wondering if there was a place for that type of thing

[03:11:28.0000] <astearns>
JakeA: mostly just www-style, I think. Or it could be a new specifiction topic...

[03:12:08.0000] <astearns>
JakeA: the houdini folks tasked with the custom layout spec might be looking for use cases

[03:49:09.0000] <gsnedders>
So what's happening with the Ruby stuff? Are browsers implementing the stuff in the W3C spec?

[03:54:26.0000] <MikeSmith>
annevk: about http://w3c-test.org/conformance-checkers/html/elements/a/href/userinfo-password-contains-pile-of-poo-novalid.html

[03:54:32.0000] <MikeSmith>
<a href="http://foo:💩@example.com"></a>

[03:54:44.0000] <MikeSmith>
that should actually be valid, right?

[03:55:05.0000] <Ms2ger>
gsnedders, I wish I knew

[03:56:37.0000] <annevk>
MikeSmith: yeah, don't really see why it wouldn't be

[03:56:48.0000] <MikeSmith>
ok

[03:56:49.0000] <annevk>
MikeSmith: well perhaps <a> being empty is a problem?

[03:56:59.0000] <MikeSmith>
nah that's not the intent

[03:57:36.0000] <MikeSmith>
I wrote that test intending for it to just test whether pile-of-poo is allowed in the password part

[03:58:42.0000] <MikeSmith>
annevk: so <a href="http://💩:foo⊙ec"></a> should be valid too?

[03:58:55.0000] <MikeSmith>
pile-of-poo in username part

[03:59:06.0000] <annevk>
yeah

[03:59:09.0000] <MikeSmith>
k

[03:59:11.0000] <MikeSmith>
thanks

[04:36:40.0000] <gsnedders>
Ms2ger: bah

[04:46:50.0000] <GPHemsley>
Periodic reminder that the RFC 2119 disclaimer has an erratum.

[04:47:18.0000] <GPHemsley>
Since nobody seems to know that.

[04:50:52.0000] <GPHemsley>
Errata ID 499

[04:50:53.0000] <GPHemsley>
http://www.rfc-editor.org/errata_search.php?rfc=2119

[05:01:51.0000] <annevk>
Seems like it has a bunch of typos. I remember Ian pointing out "NOT RECOMMENDED" once

[05:10:23.0000] <jgraham>
Not sure I even agree with the first two corrections there

[05:13:45.0000] <GPHemsley>
jgraham: I'm talking specifically about a single erratum.

[05:19:44.0000] <annevk>
GPHemsley: http://www.rfc-editor.org/errata_search.php?eid=499 works

[05:20:03.0000] <GPHemsley>
annevk: Oh, does it? I didn't realize. I searched the HTML for an id.

[05:20:21.0000] <GPHemsley>
(And found a whole lot of other issues.)

[05:21:01.0000] <GPHemsley>
I guess I overlooked the huge form at the top.

[05:21:09.0000] <GPHemsley>
Habit, I suppose.

[06:41:41.0000] <wanderview>
JakeA: this comment makes me think again we need some kind of stale-while-invalidate method in Cache: https://github.com/slightlyoff/BackgroundSync/issues/17#issuecomment-73685856

[06:44:03.0000] <JakeA>
wanderview: can't you do that programmatically pretty easily?

[06:44:30.0000] <JakeA>
wanderview: http://jakearchibald.com/2014/offline-cookbook/#stale-while-revalidate

[06:45:59.0000] <wanderview>
JakeA: true... your statement "you're more likely to create this poor experience with the fetch event" made me think its kind of a footgun, though... would be nice to have a simpler way to DTRT

[06:46:33.0000] <wanderview>
JakeA: also, the browser could possibly optimize it if its a single method

[06:47:13.0000] <wanderview>
I guess we can just see what libraries emerge... if its necessary then maybe one of them will add a wrapper for stale-while-revalidate

[06:53:09.0000] <wanderview>
JakeA: I think part of my reason for wanting this is that we have Cache.add()... why have that convenience method but not the stale-while-revalidate one? :-)

[07:17:51.0000] <slightlyoff>
wanderview: I'm not sure a feature is justified for that. Putting everything in dev control makes it, as annevk said, something we can just advise users for. We avoided this error for Push/Notifications by design. Not sure why BG Sync is different

[07:24:12.0000] <wanderview>
slightlyoff: well... its not just something you would use for BG sync... but yea, thats fine

[07:24:59.0000] <slightlyoff>
wanderview: I don't understand. You seem to be suggesting that BG sync is somehow not simply a question of waking/sending-an-event to a SW which is in full control....why?

[07:26:04.0000] <wanderview>
slightlyoff: I'm saying stale-while-revalidate would be useful for normal fetch event handling in addition to BG sync

[07:27:23.0000] <slightlyoff>
wanderview: and I'm saying that adding a special-case API when you have the full power to do it yourself is premature

[07:27:35.0000] <slightlyoff>
wanderview: I'd like to see evidence of patterns in use, not idle speculation in bugs

[07:28:25.0000] <wanderview>
slightlyoff: when I wrote "yea, thats fine" above.. I meant I'm not pushing to add a method and we don't need to argue about it :-)

[07:28:47.0000] <wanderview>
slightlyoff: I just find it odd to have convenience methods like Cache.add() and .addAll()... but not other convenience methods

[07:28:56.0000] <wanderview>
/me shrugs

[07:29:11.0000] <slightlyoff>
it's fair

[07:29:28.0000] <slightlyoff>
I guess what I'm getting at is we could sketch out super-common uses for add and addAll

[07:29:53.0000] <slightlyoff>
stale-while-revalidate seems important, but I'm unclear how it fits into the evented lifecycle right now

[07:30:17.0000] <slightlyoff>
we've talked about waitUntil in addition to respondWith for fetch events

[07:30:42.0000] <slightlyoff>
and if we see a lot of use of that to implement stale-while-revalidate, I'd be moved to add sugar

[07:31:04.0000] <wanderview>
why would the life cycle have to change if we can already implement stale-while-revalidate with existing primitives?

[07:36:32.0000] <slightlyoff>
wanderview: well, i think it'd be a bit of a hack today

[07:36:53.0000] <slightlyoff>
wanderview: without waitUntil, you can _in theory_ be killed while doing the revalidate bit

[07:37:06.0000] <slightlyoff>
wanderview: it's unlikely to happen

[07:37:33.0000] <slightlyoff>
wanderview: but it's an interesting question, and the opportunities for better CPU/memory usage aren't well studied yet

[07:38:10.0000] <wanderview>
slightlyoff: are you saying the UA is allowed to kill the SW before cache.put() here? http://jakearchibald.com/2014/offline-cookbook/#stale-while-revalidate

[07:38:49.0000] <wanderview>
or before the cache.put() resolves I guess... would be nice if the spec said something about keeping the SW alive until in-flight network requests are complete or something

[07:39:28.0000] <annevk>
wanderview: that'd give an easy trick for keeping it alive for a long time

[07:40:40.0000] <wanderview>
annevk: is the SW allowed to be killed if there is still script running?  that seems like an easier trick to keep it alive... setTimeout(), etc

[07:41:01.0000] <annevk>
wanderview: I would imagine it can be killed after each task

[07:41:31.0000] <annevk>
wanderview: as long as it keeps track of important tasks somehow such as incoming messages so they get handled the next time

[07:43:16.0000] <wanderview>
annevk: it would be nice if the spec was explicit about this stuff :-)  but without that, I think we would want to keep the SW alive until the network response body is complete in this code:  http://jakearchibald.com/2014/offline-cookbook/#stale-while-revalidate

[07:44:27.0000] <annevk>
wanderview: well I've been asking for a more explicit lifecycle for a long time now

[08:33:41.0000] <JakeA>
annevk: wanderview: slightlyoff has asked for fetchEvent.waitUntil for this case

[08:38:34.0000] <wanderview>
JakeA: seems like a good idea... I commented in the waitUntil issue

[08:39:10.0000] <annevk>
JakeA: sure, that doesn't fix the lifecycle issue though

[08:40:06.0000] <JakeA>
annevk: as in, specing timeouts etc if a non-resolving promise is passed to event.waitUntil (for example)

[08:40:42.0000] <annevk>
JakeA: defining what happens with outstanding tasks

[08:41:03.0000] <annevk>
JakeA: making sure that the definitions are such that no fetch event can get lost, even if the UA does several reboots of the SW

[08:41:23.0000] <JakeA>
gotcha

[08:46:45.0000] <wanderview>
annevk: it seems we can improve our understanding of the life cycle with waitUntil() even if every corner case is not spec'd out yet... no?

[08:47:20.0000] <annevk>
wanderview: well, web developers have another straw to hold onto

[08:47:32.0000] <annevk>
(pessimistically put)

[08:47:49.0000] <annevk>
I'm not sure it'll help implementers much

[08:48:42.0000] <wanderview>
annevk: I think it will... I have a specific issue waitUntil() would help with... namely around not canceling networking requests that are on-going like in JakeA's stale-while-revalidate recipe

[08:48:58.0000] <wanderview>
annevk: soon gecko will cancel network requests when the SW thread is stopped

[08:49:40.0000] <annevk>
wanderview: it will cancel the SW network requests, right?

[08:49:42.0000] <wanderview>
waitUntil() seems easier to deal with than trying to infer how long to keep the SW thread alive through a heuristic there

[08:49:45.0000] <wanderview>
annevk: yes

[08:49:55.0000] <annevk>
wanderview: not new fetches coming from a worker or document?

[08:50:22.0000] <wanderview>
annevk: it will cancel a fetch() started in the SW... a worker or document that does a fetch() cancels it when you navigate away from the document

[08:50:33.0000] <wanderview>
(same thing as stopping the worker thread...)

[08:50:37.0000] <annevk>
Yeah, but if we do that then I don't understand why we don't put waitUntil() on the global...

[08:50:48.0000] <annevk>
And of course we have to protect against waitUntil() abuse

[08:51:11.0000] <wanderview>
annevk: because you can't keep a dedicated worker alive if its parent document has navigated away!  that seems... to explode my brain

[08:51:26.0000] <annevk>
It just moves the problem elsewhere, e.g. waitUntil(new Promise(() => {}))

[08:51:37.0000] <wanderview>
annevk: it seems waitUntil is SW specific because it has unique (ill defined) shutdown conditions

[08:52:11.0000] <wanderview>
annevk: all other workers have clearly defined shutdown conditions tied to a document

[08:52:19.0000] <wanderview>
as far as I understand it

[08:53:32.0000] <tobie>
annevk: is http://www.w3.org/TR/html-design-principles/ still a thing, and if not, is there something that replaces it?

[08:53:56.0000] <JakeA>
annevk: it isn't on the global because success/failure is meaningful to the event dispatcher

[08:54:06.0000] <JakeA>
in the case of install & background sync for example

[08:55:30.0000] <annevk>
tobie: there was an editor's draft I can't find that has the baby steps principle

[08:55:59.0000] <annevk>
tobie: what's written there is still valid, but it's no longer maintained

[08:56:11.0000] <annevk>
tobie: perhaps we should adopt it as a wiki page

[08:56:26.0000] <tobie>
annevk: I like that

[08:58:41.0000] <annevk>
I like the "please remember your job" appeals on public-webapps ignoring end users

[08:58:44.0000] <annevk>
Oh no, I don't

[09:03:04.0000] <tobie>
annevk: decided to stay away from this conversation too. (Well, mostly: https://twitter.com/tobie/status/561079141517524992)

[09:05:54.0000] <annevk>
lol dglazkov

[09:06:48.0000] <dglazkov>
what did I do?

[09:07:14.0000] <annevk>
dglazkov: in my example bug you posted a link to some cool techno

[09:07:25.0000] <dglazkov>
nooooo....

[09:07:48.0000] <annevk>
dglazkov: are you secretly a DJ at night?

[09:07:59.0000] <dglazkov>
omg

[09:08:02.0000] <dglazkov>
much embarrass

[09:08:14.0000] <annevk>
it's quite enjoyable

[09:09:30.0000] <dglazkov>
annevk: uh... yeah.. that was my promotion tactic... that's it

[09:09:47.0000] <dglazkov>
it wasn't a copypasta at all

[09:09:48.0000] <annevk>
hehe, "feel free to follow me on Twitter"

[09:11:51.0000] <wanderview>
annevk: JakeA: what kind of device works without power connected and without a battery? (in regards to https://github.com/slightlyoff/BackgroundSync/issues/35)

[09:12:12.0000] <JakeA>
ohhh a riddle

[09:12:28.0000] <wanderview>
just trying to understand the unicorn we are naming

[09:12:32.0000] <JakeA>
:D

[09:13:13.0000] <annevk>
wanderview: steam engine :-)

[09:13:23.0000] <wanderview>
/me proposes the .isThisThingOn attribute.

[09:13:25.0000] <jgraham>
A wind up radio? One of those watches that takes energy from your movements?

[09:13:42.0000] <jgraham>
Something with solar panels?

[09:13:44.0000] <wanderview>
the correct answer is solar powered browsers

[09:13:48.0000] <wanderview>
:-)

[09:13:50.0000] <JakeA>
wanderview: "chargingOnly" intends to mean "only sync if the device isn't discharging it's supply of power"

[09:14:03.0000] <JakeA>
but for a desktop machine, without a battery, you could say it is not charging

[09:14:15.0000] <JakeA>
because it has no battery to charge

[09:14:36.0000] <gsnedders>
What happens if it's a desktop machine currently relying on a UPS?

[09:15:05.0000] <wanderview>
JakeA: what about a power time estimate... "do the thing if we think we have enough power for more than 4 hours"... A/C power implies infinite time

[09:15:18.0000] <wanderview>
/me over complicates all the things.

[09:16:20.0000] <wanderview>
annevk: I would accept onSteamPower as an attribute

[09:17:20.0000] <annevk>
I'm okay with acOnly

[09:17:54.0000] <wanderview>
annevk: I just dislike that "ac" is hard to understand if you don't know you're talking about power

[09:18:05.0000] <annevk>
Agreed

[09:18:05.0000] <gsnedders>
/me is with wanderview here

[09:18:17.0000] <annevk>
JakeA: what was wrong with my suggestions?

[09:18:38.0000] <annevk>
JakeA: e.g. excludeBattery seems pretty clear

[09:18:51.0000] <annevk>
JakeA: or stationaryPower

[09:19:13.0000] <wanderview>
/me likes excludeBattery or something like it.

[09:19:32.0000] <wanderview>
avoidBattery

[09:19:35.0000] <wanderview>
exceptBattery

[09:19:40.0000] <wanderview>
ohGodNotTheBattery

[09:19:50.0000] <annevk>
preserveBattery

[09:19:51.0000] <JakeA>
haha

[09:19:57.0000] <wanderview>
annevk++

[09:20:07.0000] <JakeA>
wanderview: annevk: *Battery could mean devices with a battery

[09:20:18.0000] <JakeA>
nothing to do with the battery discharging

[09:20:29.0000] <wanderview>
JakeA: preserveBattery seems kind of clear

[09:20:42.0000] <annevk>
JakeA: yeah, that seems covered

[09:20:55.0000] <wanderview>
"kind of clear"... I aim high!

[09:21:04.0000] <annevk>
JakeA: my laptop has a battery, but preserving isn't needed if power is plugged in

[09:21:30.0000] <JakeA>
hm, it sounds like it'll still happen on battery but preserve it somehow, like a low power mode

[09:21:34.0000] <JakeA>
maybe that's just me

[09:22:06.0000] <JakeA>
notDuringDischarge but ew discharge

[09:22:16.0000] <JakeA>
ugh

[09:22:19.0000] <annevk>
I mean the UA might still do it on battery I think

[09:22:30.0000] <annevk>
I don't think we want to give the app absolute control here

[09:22:41.0000] <annevk>
All these things are hints

[09:22:46.0000] <wanderview>
JakeA: I think preserveBattery makes sense... because the battery will be used as long as the device is on... and yea... gives wiggle room for the UA

[09:23:36.0000] <wanderview>
bikeshedding names makes me hungry

[09:23:54.0000] <JakeA>
The only use-case I have for this option is deferring it to a settings menu for the user, so the UA doing something different breaks that

[09:24:35.0000] <annevk>
I don't follow that

[09:25:02.0000] <JakeA>
So, my podcast app has a menu, where I the user can say "only sync when plugged in please"

[09:25:25.0000] <JakeA>
Does the option have a use outside of user settings?

[09:25:45.0000] <annevk>
Not sure, but if it's up to the user it shouldn't be up to the app

[09:26:37.0000] <JakeA>
right, ideally all syncs should be in one settings menu in the browser, and the user gets to decide what connectivity or battery state they're restricted to

[09:26:55.0000] <JakeA>
but for that to work, you need to display the sync's description

[09:26:58.0000] <JakeA>
which is set by the app

[09:27:07.0000] <JakeA>
which means you get that problem

[09:27:36.0000] <JakeA>
(https://github.com/slightlyoff/BackgroundSync/issues/29)

[09:27:46.0000] <annevk>
yeah, the user would just disable it for all syncs

[09:28:45.0000] <JakeA>
but I'm happy for my podcast app to update feeds whenever, but not download podcasts - actually that means the sync still happens, the battery api would be used within the sync in that case

[09:28:46.0000] <JakeA>
hmm

[09:43:27.0000] <wanderview>
fyi... if anyone is interested in testing the gecko service worker implementation... I'll be posting updated builds here until everything is in the tree:  http://blog.wanderview.com/sw-builds/

[09:49:50.0000] <Domenic>
Anyone else have opinions on this? https://twitter.com/streamsstandard/status/565196470836396033

[09:50:24.0000] <wanderview>
Domenic: I prefer silent... you're asking it to enter a state... its already in that state... not an error (in my opinion)

[09:50:49.0000] <wanderview>
/me lunches

[10:00:50.0000] <jgraham>
annevk: Does fetch have enough infrastructure for specifying a HTTP-based protocol? Or how does one do that? The context is the WebDriver spec which specifies a HTTP-based API for remote controlling browsers. So it feels like you need some mechanism for parsing requests and constructing responses.

[10:01:19.0000] <jgraham>
current spec is https://w3c.github.io/webdriver/webdriver-spec.html

[10:07:48.0000] <JakeA>
Domenic: agree with wanderview. It's in the spirit of clearTimeout(123456)

[10:37:46.0000] <annevk>
jgraham: well everything XHR and fetch() can do...

[10:37:56.0000] <annevk>
jgraham: it depends on the details I guess

[10:38:43.0000] <jgraham>
Yeah, so I wonder if refering to Fetch is the right thing

[10:39:02.0000] <jgraham>
I wasn't sure it had all the bits needed for a server though, since it's all about being a client

[10:56:02.0000] <annevk>
Ooh

[10:56:26.0000] <annevk>
Not sure, Fetch is heavily client-focused

[10:59:41.0000] <Domenic>
I think you're underselling yourself annevk :). Service worker is like a server in many ways and the Fetch primitives (like Response) seem to be working pretty well there

[11:03:15.0000] <jgraham>
So this is literally my internal monolouge on the subject played out on irc :)

[11:09:58.0000] <wanderview>
that would be an interesting experiment... build a web server where network requests produce an onfetch event and you respondWith() the response

[11:10:11.0000] <wanderview>
would be a cool node module

[11:10:47.0000] <wanderview>
just need some streams support :-)

[11:32:09.0000] <Domenic>
I really should start putting together some demos with the streams polyfill that's already all ready to go

[11:32:11.0000] <Domenic>
In Node especially

[11:32:31.0000] <Domenic>
Although to be fair there's https://streams.spec.whatwg.org/#example-rs-pull :P

[12:01:11.0000] <botie>
hsivonen, at 2015-02-10 07:44 UTC, MikeSmith said: when you have a minute please take a look at the following and let me know if you're OK with it. Basically it just refines fatal-error messages for files with content-type mismatches to include mention of the URL for the file. It seems safe to do since it's

[12:01:11.0000] <botie>
not leading any info the user doesn't already know. https://github.com/validator/validator/commit/c98215c55d2a8cd433877da23119 and at 2015-02-10 07:44 UTC, MikeSmith said: https://github.com/validator/validator/commit/c98215c55d2a8cd433877da2311916c9ebbfd342

[13:05:27.0000] <annevk>
wanderview: your blog needs some TLS

[13:05:43.0000] <wanderview>
annevk: not supported on custom domains with github pages... I checked

[13:05:53.0000] <wanderview>
annevk: I put the images on people.mozilla.org behind https, though

[13:06:29.0000] <annevk>
wanderview: you would need to know that in advance to avoid being spoofed :-)

[13:06:57.0000] <annevk>
wanderview: that's kinda shitty with GitHub, but I guess it makes some sense

[13:07:09.0000] <ondras>
firebase hosting uses tls by default

[13:07:19.0000] <ondras>
just in case.

[13:07:25.0000] <wanderview>
annevk: if you just do wanderview.github.io... https works... but there is no way to specify a cert for a custom domain

[13:12:33.0000] <Domenic>
wanderview: I indirect behind CloudFlare because I am lazy...

[13:12:54.0000] <wanderview>
Domenic: is there a guide on setting that up?

[13:13:36.0000] <Domenic>
wanderview: it is pretty simple, and you can use terinjokes as your personal tech support. Basically you follow https://help.github.com/articles/setting-up-a-custom-domain-with-github-pages/

[13:14:14.0000] <wanderview>
ok... I've done that using dnsimple as my DNS provider

[13:14:49.0000] <wanderview>
Domenic: cloudflare lets you get ssl on github pages, though?  not sure I understand how that works

[13:15:27.0000] <Domenic>
wanderview: yeah cloudflare gives you free TLS on your custom domain.

[13:15:38.0000] <Domenic>
It then proxies gh-pages in the background

[13:15:55.0000] <terinjokes>
if you upgrade to Pro you can upload the custom cert

[13:15:58.0000] <wanderview>
ah.... I see the diagrams here now:  https://www.cloudflare.com/ssl

[13:17:14.0000] <terinjokes>
nvm, i read "custom cert" rather than "custom domain"

[13:18:21.0000] <wanderview>
Domenic: terinjokes: thanks!  I'll make a note of that for a weekend project :-)

[15:21:35.0000] <JonathanNeal>
In today’s world of browsers and machines, does it improve performance to cache deep objects like toString = Object.prototype.toString?

[15:23:48.0000] <gsnedders>
JonathanNeal: in cold code? yes; in hot code? you're saving *at most* one class check per access

[15:23:59.0000] <gsnedders>
(of course in cold code you shouldn't care about the performance!)

[15:26:45.0000] <JonathanNeal>
gsnedders: Interesting. I still see this pattern in new scripts (and to be clear and narrow I’m referring to caching only for the sake of shortening the lookup). So, should we drop it? Did it once have significant impact on performance in old IE or something?

[15:27:36.0000] <gsnedders>
JonathanNeal: it did everywhere in the days before JITs

[15:28:01.0000] <gsnedders>
you might see a small performance increase in really tight loops, but by the time you're doing toString.call you've probably lost

[15:28:18.0000] <gsnedders>
But benchmark and don't take my word for it, etc.

[15:28:57.0000] <JonathanNeal>
I’ve been looking for existing benchmarks. Are there some keywords I haven’t used that might help me in my search?

[15:29:10.0000] <gsnedders>
I dunno!

[15:30:16.0000] <Domenic>
You should be benchmarking a larger app anyway

[15:30:35.0000] <Domenic>
Your code will be cold or hot only depending on the context of the app it's running in

[15:30:44.0000] <gsnedders>
And quite possibly inlined into it

[15:35:20.0000] <JonathanNeal>
Thanks gsnedders, Domenic. In our polyfill project, there’s a small discussion happening as to whether we should drop local variables that cache deep properties. I can’t find an existing benchmark, so I’ll just recommend we keep the local variables and test to see if we can drop them.

[15:36:00.0000] <MikeSmith>
does anybody know, when you do a multipart/formdata file upload in a browser running under Windows, it seems like it sets a Content-Type based on the file extension

[15:36:10.0000] <Domenic>
Or you could actually benchmark your own code instead of looking for a benchmark of someone else' code

[15:36:42.0000] <JonathanNeal>
Domenic: That’s what I thought I just said. Sorry if I miscommunicated.

[15:37:06.0000] <Domenic>
hmm ok

[15:37:22.0000] <Domenic>
sorry then

[15:37:23.0000] <JonathanNeal>
I did miscommunicate. I meant, s/test/test our library ourselves


2015-02-11
[16:49:48.0000] <JonathanNeal>
Is there any talk on allowing Elements https://dom.spec.whatwg.org/#elements to apply to more than query/queryAll?

[18:34:49.0000] <karlcow>
o_O https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0585.html

[18:36:45.0000] <karlcow>
same person? https://twitter.com/marcfawzi/with_replies

[22:25:18.0000] <MikeSmith>
karlcow: that's actually a natural-language chatter bot somebody wrote that seems to have gotten out of hand

[22:25:49.0000] <MikeSmith>
karlcow: the clue is that his name is an anagram of the French word for "wingnut"

[22:28:35.0000] <karlcow>
pfew… I had doubts.

[22:28:37.0000] <karlcow>
;)

[00:23:02.0000] <annevk>
Oh look, moving DOM attributes to prototypes is back for another round on blink-dev

[00:23:10.0000] <annevk>
Please place your bets now

[00:36:12.0000] <MikeSmith>
haha

[00:38:23.0000] <MikeSmith>
I'll take any bet against that at 40-1

[00:40:06.0000] <MikeSmith>
5 years from now we'll still be waiting on that to happen

[00:42:07.0000] <annevk>
http://w3cmemes.tumblr.com/post/35475527654/theyll-remove-h-264-support-any-moment-now

[00:42:40.0000] <annevk>
Bit more hopeful that it sticks though, provided the perf claims are true this time around

[00:55:11.0000] <MikeSmith>
yeah I'm just trolling

[00:55:30.0000] <MikeSmith>
I'm actually optimitistic too

[00:56:19.0000] <MikeSmith>
I know haraken's put a ton of work into trying to make it happen

[01:29:25.0000] <annevk>
I wish GitHub had an option to ignore a thread until you're mentioned again

[01:30:04.0000] <annevk>
Sometimes people pull me in to ask something but then the thread goes on after for a long time without needing any input from me

[01:30:27.0000] <annevk>
I guess I'm just going to unsubscribe in those cases and require out-of-band contact

[01:48:27.0000] <annevk>
/me replies to everything BackgroundSync

[02:22:37.0000] <jgraham>
darobin: Was there one of those "file a bug on this spec" implementations that's trivial to drop into ReSpec specs?

[02:25:44.0000] <darobin>
jgraham: you mean a script that, say, takes your selection and uses that to fill out the bug?

[02:25:53.0000] <darobin>
or just generating a link to the bug tracker?

[02:27:28.0000] <jgraham>
darobin: More like the former. Something that allows me to somehow file a bug saying "this part of the spec sucks" where it is obvious what "this" is, without leaving the spec

[02:28:57.0000] <darobin>
jgraham: no, ReSpec deliberately stops at generation and does not take care of adding interactivity down the line

[02:29:18.0000] <darobin>
jgraham: but if this is for a bugzilla tracker there's a script you can use, not great but sort of operational

[02:29:55.0000] <jgraham>
"Not great but sort of operational" sounds better than "not". Which is what we currently have.

[02:30:05.0000] <darobin>
http://www.w3.org/html/wg/drafts/html/master/js/bug-assist.js

[02:30:36.0000] <jgraham>
darobin: Thanks!

[02:30:54.0000] <darobin>
it will take selected text into account, but it won't report stuff like scrolling offset if the user just clicks the button without selection

[02:31:00.0000] <darobin>
a pleasure

[03:20:18.0000] <annevk>
JakeA: I don't really think it's desirable to expose HTTP push directly

[03:20:52.0000] <annevk>
JakeA: it's rather nice that it's transparent to the application what protocol is in use

[03:22:32.0000] <JakeA>
annevk: I had a half-baked idea of response.push containing an array of {request, response}. But I agree I don't think it's particularly important

[03:23:08.0000] <annevk>
I would imagine you'd get a distinct pushfetch event or some such

[03:23:36.0000] <annevk>
But it seems a bit like a hack to expose network protocol details in that manner

[03:24:21.0000] <annevk>
Because what you'll get is exactly what he proposes, that applications become dependent on the protocol

[03:24:41.0000] <JakeA>
yeah, also I really don't know enough about http/2 to make a decent call here. I'm not even sure if pushed resources are part of a specific response or part of the general stream

[03:24:52.0000] <JakeA>
agreed

[04:21:44.0000] <annevk>
"Your message to Unbearable awaits moderator approval" IETF lists suck so much

[04:22:07.0000] <annevk>
(same for the WHATWG list, but at least it's just a onetime affair)

[04:25:02.0000] <annevk>
https://tools.ietf.org/html/draft-balfanz-https-token-binding-00#section-3.4 is funny. "an XML HTTP request", "the XmlHttpRequest object", "the XmlHttpRequest", "web origin", ... oh my

[06:25:37.0000] <JonathanNeal>
After watching https://www.youtube.com/watch?v=XRYN2xt11Ek I have been wondering if there’s a place for their Event Model in native JS so I’ve thrown this very rough demo together: http://sandbox.thewikies.com/EventObserver/

[06:26:51.0000] <annevk>
JonathanNeal: comes up every now and then within TC39

[06:27:47.0000] <annevk>
JonathanNeal: I stopped working on https://gist.github.com/annevk/5238964 when I learned that, but I don't think much progress has been made

[06:29:05.0000] <JonathanNeal>
Yea, I like that.

[06:45:25.0000] <JonathanNeal>
I wanted to use the name `then` instead of `forEach`, but in Promises you never fire the onFulfilled method multiple times, right?

[06:47:12.0000] <annevk>
JonathanNeal: right, a promise either returns a value or throws, similar to a function

[08:13:57.0000] <JonathanNeal>
annevk: how could I bring this to folks-that-know-how-to-pitch-ideas attention?

[08:28:18.0000] <annevk>
JonathanNeal: I'm not sure what you mean

[09:12:13.0000] <Domenic>
annevk: I think Unsubscribe does that actually. Unsubscribe is not "Ignore"

[09:24:06.0000] <benjamingr>
Domenic: I'm in a meeting about DOM web components and other web standards stuff  - do I send anyone from google or another place pics?

[09:24:39.0000] <Domenic>
benjamingr: I don't really understand? Why would anyone want pictures of your meeting?

[09:26:02.0000] <benjamingr>
Haha, don't know - it's not my meeting at all. I just got invited and there are 200 people here. Google and other companies has this thing where it likes meetings and stuff so I wanted to know if anyone would care.

[09:37:34.0000] <rafaelrinaldi>
benjamingr take a selfie of you doing a gang sign on stage and send us

[09:50:28.0000] <benjamingr>
Hah sure

[10:18:25.0000] <annevk>
Domenic: oh okay

[10:35:35.0000] <wanderview>
is SharedArrayBuffer a spec'd thing?

[11:09:14.0000] <annevk>
wanderview: oh is that out?

[11:09:45.0000] <annevk>
wanderview: in December it seemed like it was mostly lth's idea

[11:21:14.0000] <wanderview>
annevk: I was told in #jsapi that its not out yet

[11:28:45.0000] <Domenic>
wanderview: I don't know if this is related but it's the arraybuffer technology I'm most excited about: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer/transfer

[11:38:38.0000] <JonathanNeal>
I’m trying to formalize an idea of EventObservers http://sandbox.thewikies.com/EventObserver/ What would be the place to pitch this? DOM mailing list?

[11:39:18.0000] <caitp->
which one

[11:39:18.0000] <botie>
i think which one is correct?

[12:02:35.0000] <smaug____>
JonathanNeal: I guess dom mailing list

[12:03:08.0000] <JonathanNeal>
smaug____: thanks!

[13:19:37.0000] <annevk>
Domenic: SharedArrayBuffer is shared memory

[13:19:50.0000] <annevk>
Domenic: it's much more exciting and also much more scary

[13:20:03.0000] <Domenic>
@_@

[13:20:53.0000] <caitp->
shmemory

[13:33:13.0000] <wanderview>
annevk: Domenic: yea, but kind of cool we can use the ideas in this issue to share the buffers from a pipe with another worker for processing, etc:  https://github.com/whatwg/streams/issues/253


2015-02-12
[17:06:21.0000] <karlcow>
http://engineering.flipboard.com/2015/02/mobile-web/

[17:13:15.0000] <MikeSmith>
60fps on the mobile Web, problem solved

[17:13:32.0000] <MikeSmith>
we'll just all use canvas!

[17:14:10.0000] <MikeSmith>
it's amazing that nobody's ever thought to do this before

[17:16:23.0000] <karlcow>
MikeSmith: they speak about Bespin in the article :)

[17:31:54.0000] <wanderview>
Accept is not a simple CORS header? but things like Accept-Language are?

[17:32:25.0000] <wanderview>
oh... nm

[00:20:32.0000] <zcorpan>
annevk: https://www.chromestatus.com/metrics/feature/timeline/popularity/465 looks like it's not declining particularly fast

[00:21:27.0000] <annevk>
zcorpan: yeah

[00:22:11.0000] <annevk>
zcorpan: still seems sane for browsers to warn about it though

[00:22:30.0000] <zcorpan>
maybe it's more effective to not talk about removing the feature but only talk about why using it is bad

[00:22:41.0000] <annevk>
zcorpan: e.g. the jQuery crowd started acting based on this I believe

[00:23:52.0000] <annevk>
zcorpan: and that latest thread was just ridiculous, someone arguing that you need synchronous fetching for scrolling...

[00:24:35.0000] <zcorpan>
yes

[00:27:59.0000] <Domenic>
I wonder if we could quarantine it to only pages that we already know are using it

[00:28:43.0000] <Domenic>
origins i guess would be the granularity boundary

[00:30:04.0000] <annevk>
Probably eTLD+1 given document.domain, but maybe

[00:35:35.0000] <annevk>
https://www.youtube.com/watch?v=PqHL9hKhX6I This <core-list> seems to be essentially what React is doing, just in a different way

[00:36:34.0000] <annevk>
So the argument that putting a lot of items in the DOM and rendering that quickly is impossible, is not disproven

[01:09:13.0000] <annevk>
philipj: you want to support promises from the prefixed version of the Fullscreen API?

[01:09:41.0000] <philipj>
annevk: no

[01:09:46.0000] <philipj>
did I write a terrible typ?

[01:11:25.0000] <philipj>
so, it would probably not be hard to support it for the prefixed APIs, I'm just not sure what the point would be

[01:11:53.0000] <philipj>
if shipped together with the unprefixed API, people who adapt to use promises should also stop using the prefixed API

[01:13:03.0000] <philipj>
annevk: I have "Read Fullscreen mail" on this weeks todo list, if the sudden interest in all things fullscreen seems out of characters

[01:14:26.0000] <annevk>
philipj: it sounded like you wanted to add promises before the unprefixed version was shipped

[01:14:38.0000] <annevk>
philipj: but perhaps you just meant added to the specification, which seems fine

[01:14:58.0000] <annevk>
philipj: like you I have taken a Fullscreen break

[01:15:22.0000] <annevk>
philipj: I still need to look at Hixie's changes to the event loop to allow for synchronization with animation frames

[01:15:54.0000] <annevk>
philipj: also, I guess we need to decide whether the promise needs to reject or return false or some such

[01:16:30.0000] <philipj>
annevk: I mean to the spec, and to only return the promises from the unprefixed API, by whatever implementation strategy is required to make it so

[01:16:52.0000] <philipj>
since it's a return value I think it's easy to just not update the prefixed IDL

[01:17:15.0000] <philipj>
annevk: you mean when the fullscreen ready check fails?

[01:21:42.0000] <annevk>
philipj: yeah

[01:23:25.0000] <annevk>
Okay, so the callback from HTML is "run the fullscreen rendering steps" and a timestamp

[01:23:50.0000] <annevk>
philipj: do you know what Fullscreen would use the timestamp for?

[01:24:41.0000] <philipj>
annevk: no idea, that sounds odd

[01:25:38.0000] <annevk>
https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9 step 8.8

[01:40:25.0000] <JakeA>
annevk: re BackgroundSync ux: my current thinking is that one-off syncs should create some kind of sticky notification saying "Waiting to sync" or similar until the sync successfully completes

[01:40:39.0000] <JakeA>
No idea what to do with periodic syncing though

[01:41:06.0000] <annevk>
JakeA: where would that display?

[01:52:19.0000] <JakeA>
annevk: on Android, same place as native notifications

[01:52:52.0000] <annevk>
JakeA: is one-off a thing that native applications get too?

[01:53:32.0000] <annevk>
/me only remembers periodic background update UX

[01:54:26.0000] <philipj>
annevk: it sure looks like it's just passed for good measure, in case it's needed

[01:56:16.0000] <annevk>
philipj: the weird thing about Hixie's setup is that I can't queue some set of steps for this callback

[01:56:57.0000] <annevk>
philipj: I'd imagine there being some slot that has the set of actions that needs to be performed

[01:57:12.0000] <annevk>
philipj: but perhaps we need to define that ourselves as it's different for all the different cases?

[01:57:26.0000] <philipj>
annevk: can't you do whatever you want in "the fullscreen rendering steps"?

[01:57:38.0000] <annevk>
philipj: yeah I can

[01:58:09.0000] <annevk>
philipj: it's just that the whole task queueing model surrounding it does a lot more for you, but I guess that's oaky

[01:58:12.0000] <annevk>
okay*

[01:58:35.0000] <philipj>
I had imagined that there would be a generic bucket called "run the animation frame tasks" right before the callbacks, and that it would be possible to queue such tasks

[02:00:12.0000] <philipj>
if this spec is implemented quite literally it seems like a bit of an odd polling model

[02:03:15.0000] <JakeA>
annevk: https://developer.android.com/reference/android/app/AlarmManager.html see set(). That doesn't seem to deal with connectivity though

[02:04:17.0000] <annevk>
philipj: well it's something like that, except without the generic bucket

[02:04:34.0000] <annevk>
philipj: presumably so that all these things happen in the correct order?

[02:05:08.0000] <philipj>
annevk: I guess, although a task queue also has an order same as regular tasks really

[02:05:53.0000] <annevk>
JakeA: yeah, it seems you have wake-on-time, wake-on-network, wake-periodic-on-network, wake-on-times

[02:06:01.0000] <philipj>
If some of these steps (like resize/scroll) can influence later steps then fixinf the order is reasonable

[02:06:31.0000] <annevk>
philipj: so I'd imagine we have a slot on the global and then make HTML's callback run the code in that slot

[02:06:42.0000] <JakeA>
annevk: I don't see network stuff there

[02:06:48.0000] <annevk>
philipj: which is effectively the same as queuing a task except having it run at a specific time

[02:07:02.0000] <annevk>
JakeA: sorry, was combining that with what we have

[02:07:11.0000] <annevk>
JakeA: as use cases

[02:07:14.0000] <JakeA>
ahh gotcha

[02:07:18.0000] <JakeA>
yeah

[02:07:38.0000] <annevk>
iOS has "Background App Refresh"

[02:07:40.0000] <JakeA>
Seems that Android makes wake-when-reconnected quite difficult http://stackoverflow.com/questions/15698790/broadcast-receiver-for-checking-internet-connection-in-android-app

[02:08:22.0000] <philipj>
annevk: I guess your rendering steps are going to do nothing at all most of the time?

[02:08:22.0000] <annevk>
I think alarm/calendaring is probably related to the "notifications" permission

[02:08:40.0000] <philipj>
just see if there's a pending task and if so run it?

[02:08:41.0000] <annevk>
philipj: yeah, I would expect the slot to be empty mostly

[02:09:13.0000] <annevk>
philipj: that's why I kinda wish Hixie had formalized the slot idea, perhaps I should ask

[02:09:25.0000] <philipj>
yeah, probably should

[02:09:36.0000] <philipj>
also, the name "run the fullscreen rendering steps" probably won't make sense

[02:09:55.0000] <philipj>
nothing is being rendered, it's just events being fired and state being twiddled

[02:11:16.0000] <annevk>
philipj: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28001

[02:13:14.0000] <annevk>
JakeA: perhaps the UX should just be asking for "background updates"

[02:13:37.0000] <annevk>
JakeA: and if you have given both "notification" and "background updates" you can get alarms

[02:14:20.0000] <JakeA>
annevk: on Chrome, I believe we roll background & notification into one permission prompt (for push anyway)

[02:15:05.0000] <annevk>
I remember not liking what I heard about push and Chrome

[02:15:13.0000] <annevk>
but I don't really recall the specifics

[02:15:56.0000] <philipj>
annevk: thanks

[02:40:38.0000] <JakeA>
annevk: there's a bit of magic at the moment as we ease ourselves into the idea of sites running code in the background

[02:41:09.0000] <JakeA>
annevk: specifically, a push event must show a notification unless the site has focus

[02:41:29.0000] <annevk>
JakeA: I'm not sure that's true

[02:41:48.0000] <annevk>
JakeA: if I granted a site the permission to do work in the background, I don't think a notification would need to be shown

[02:42:55.0000] <JakeA>
annevk: yeah, but there's a lot of (justified imo) worry around privacy issues

[02:43:10.0000] <JakeA>
So we want users to be aware that a site did background work

[02:43:29.0000] <JakeA>
As it can be used to track location at an IP level

[02:44:03.0000] <JakeA>
The hope is to relax this as we work out the UX and user sentiment

[02:45:48.0000] <annevk>
I definitely support making it discoverable and easy to disable, etc. But prominent UI whereas native gets away with a better experience does not seem acceptable

[02:46:07.0000] <annevk>
So yeah, that was the thing that irked me about Chrome and push

[02:46:31.0000] <annevk>
I think mt is handling that mostly from Mozilla, but maybe I should verify that

[03:03:14.0000] <annevk>
Hmm... CORS filtered response does not filter out Set-Cookie and Set-Cookie2 at all times, oops

[03:11:34.0000] <annevk>
Fixed

[03:15:30.0000] <JakeA>
annevk: once we have a better way to ensure the user knows what's able to run in the background, that restriction will be lifted

[03:16:17.0000] <annevk>
I think what was bothering mt was that it was influencing API design

[03:16:34.0000] <JakeA>
annevk: the big worry is users that are tricked into accepting push for something friendly, but it abusing that without the user knowing

[03:23:33.0000] <annevk>
Yeah it's definitely a tricky concept

[03:24:51.0000] <annevk>
But I think the problem was that it got to point where Google UX decisions started to influence the API in a way that didn't work for others

[03:25:02.0000] <annevk>
Need to check with mt what the latest is

[03:27:05.0000] <JakeA>
annevk: I'm not aware of API changes that have resulted from this privacy caution

[03:28:12.0000] <JakeA>
annevk: the only privacy API change I'm aware of is the requirement to encrypt the push body so the message server can't read it. I think that came mainly from Mozilla

[03:28:45.0000] <annevk>
JakeA: that's the protocol, no?

[03:28:55.0000] <annevk>
JakeA: that sounds like a good change

[03:29:50.0000] <JakeA>
annevk: it's not the protocol, tls is already required for data transfer

[03:32:21.0000] <JakeA>
annevk: the requirement is, when you register for push, the reg object gives you a key & an encryption format, which you send to your server. Before your server sends a message to the messaging-service, you encrypt the body using that format & key.

[03:33:17.0000] <JakeA>
The messaging-service sends it to the phone, which it decrypts

[03:34:06.0000] <JakeA>
So the messaging service doesn't get to see the body of the push

[03:34:27.0000] <JakeA>
Pretty cool, but really complicates usage & API

[03:36:18.0000] <annevk>
I wonder if that could have been done in a simpler way by making use of TLS which is already in place, but I guess people tried to think of that already

[03:37:25.0000] <JakeA>
annevk: if you can think of a simpler way, it's still up for debate. We're shipping without message bodies in the meantime.

[03:37:44.0000] <JakeA>
I can't think of a way, but my crypto knowledge is weak

[03:40:31.0000] <annevk>
It seems like you need something like this

[03:41:33.0000] <annevk>
JakeA: so what parts will the intermediary learn? Just the origin involved?

[03:42:42.0000] <JakeA>
annevk: it'll know the sender & obviously the time of each message

[03:43:05.0000] <annevk>
JakeA: yeah, seems hard to avoid

[03:43:26.0000] <JakeA>
Oh course, if push bodies were unencrypted, there's nothing preventing a site adding their own encryption

[03:43:54.0000] <JakeA>
But forcing it seems sensible when the browser/os/messaging service aren't all the same provider

[03:44:05.0000] <annevk>
Yeah, but as we learned from HTTP, optional is not good long term

[03:45:40.0000] <JakeA>
annevk: btw, haven't managed to get hold of Hixie, are you up for a call on SW & postMessage tomorrow evening?

[03:45:41.0000] <annevk>
JakeA: the API draft doesn't seem to include this encryption stuff yet

[03:46:14.0000] <JakeA>
annevk: yeah, it's still being debated, although I'm not sure where exactly (but I know Mozilla is involved)

[03:47:22.0000] <annevk>
JakeA: I feel like I haven't been involved enough in the development of the various postMessage schemes to know what we should be doing

[03:48:10.0000] <JakeA>
For the postMesage stuff, I'm still circling on clients receiving messages at navigator.serviceWorker.onmessage, and serviceworker receiving them at self.onmessage. It breaks some of the symmetry, but it's easy to use and doesn't break existing APIs

[03:48:22.0000] <JakeA>
annevk: if not Hixie, who has enough of this stuff in their head?

[03:48:57.0000] <annevk>
JakeA: maybe smaug____

[03:49:50.0000] <JakeA>
smaug____: what say you to some form of synchronous communication to help us get unstuck on ServiceWorker & postMessage?

[03:50:01.0000] <JakeA>
(and what timezome are you in?)

[03:50:27.0000] <annevk>
JakeA: so the idea is navigator.serviceWorker.onmessage/navigator.serviceWorker.postMessage and self.onmessage/client.postMessage on the other side?

[03:50:28.0000] <smaug____>
/me lives in smaug-timezone as someone put it couple of years ago

[03:50:42.0000] <smaug____>
JakeA: I live in Helsinki, so EET

[03:50:59.0000] <annevk>
JakeA+2h

[03:51:33.0000] <smaug____>
sync communication ?

[03:52:11.0000] <JakeA>
smaug____: a video/voice call

[03:53:27.0000] <JakeA>
annevk: swClient.postMessage would land at navgiator.serviceWorker.onmessage, navigator.serviceWorker,controller.postMessage would land at self.onmessage

[03:53:36.0000] <annevk>
JakeA: I think that if we try to explain this in terms of message channels (which I think we need in order for this to work) we might get somewhere

[03:54:31.0000] <smaug____>
JakeA: eh, I thought you were talking about synchronous communication API

[03:54:34.0000] <smaug____>
apparently no

[03:55:07.0000] <JakeA>
annevk: I guess it could be navigator.serviceWorker.controller.onmessage, but I was hoping there'd be a way for a client to listen for messages from *any* SW, rather than having to add onmessage to each and monitor for new SWs appearing & listen to those too

[03:55:21.0000] <smaug____>
/me has no idea what the issue is

[03:55:51.0000] <JakeA>
smaug____: we're trying to work out how a serviceworker could send a message to a specific client on the same origin

[03:56:00.0000] <annevk>
JakeA: that is why you need to look into message channels and how you explain the underlying functionality

[03:56:01.0000] <JakeA>
where a client is a window/worker/sharedworker

[03:56:13.0000] <JakeA>
annevk: yeah, that's fair

[03:56:18.0000] <annevk>
JakeA: currently you're just trying to invent some sugar without understanding what it comes down to

[03:57:50.0000] <JakeA>
annevk: yeah, I guess I'm trying to avoid ending up with a semantically pure but virtually impossible to use API. But I should at least be able to explain it in terms of the channel stuff.

[04:01:17.0000] <smaug____>
I don't think I know enough about the issue to say anything useful. I'd try to follow the SharedWorker model if possible, but perhaps there is some reason why that doesn't work here

[04:04:15.0000] <annevk>
So the main problem with SW is that it can come and go. So its port can get GC'd at any point but we don't really want to lose any messages I think...

[04:04:58.0000] <annevk>
So you need some kind of intermediary place where the messages go first. And then whenever an SW boots up they get transmitted until the SW shuts down again.

[04:04:59.0000] <JakeA>
smaug____: The browser may terminate the serviceworker while it isn't being used to save memory, so the sharedworker model of connect events & keeping posts in scope doesn't work. Also, in the sharedworker model the client must explicitly connect to the sharedworker before the sharedworker can contact the client. I'm hoping the serviceworker can send

[04:04:59.0000] <JakeA>
messages to specific clients, and all the client has to do to receive them is register an onmessage event somewhere

[04:05:46.0000] <annevk>
JakeA: what if the client instead registers an onserviceworkerconnect handler?

[04:05:56.0000] <annevk>
JakeA: and gets handed a port there

[04:06:17.0000] <JakeA>
annevk: when would that fire?

[04:06:30.0000] <annevk>
But yeah, then you have the opposite problem, how to send to the SW

[04:07:18.0000] <JakeA>
annevk: I think that problem is solved right? serviceWorkerInstance.postMessage to self.onmessage doesn't feel controversial.

[04:07:34.0000] <JakeA>
although I guess there's a reason sharedworker doesn't have something that simple

[04:07:46.0000] <annevk>
JakeA: that is controversial since you can't explain it in terms of ports

[04:07:57.0000] <annevk>
JakeA: so I have no idea how it works, exactly

[04:08:02.0000] <JakeA>
hm

[04:08:46.0000] <annevk>
Perhaps something like BroadcastChannel but specific to this scenario?

[04:09:42.0000] <JakeA>
that model feels like a better fit, but directed at a specific client. It'd be great if it could reuse broadcastChannel fundamentals because Chrome could implement both

[04:10:13.0000] <annevk>
So BroadcastChannel could work if you have some identifier unique to the client...

[04:11:30.0000] <annevk>
JakeA: I can talk tomorrow night, but I rather not, and also earlier the better

[04:11:32.0000] <JakeA>
annevk: are you suggesting that the developer has to filter out the messages or that the spec does that?

[04:12:00.0000] <annevk>
JakeA: hmm lunch

[04:12:25.0000] <annevk>
JakeA: my idea was we give the dev some identifier for BroadcastChannel (perhaps through a sublcass) so they get one unique for a particular client

[04:12:32.0000] <annevk>
back later

[04:13:16.0000] <JakeA>
have a good'un. I really should be writing a talk :(

[04:44:38.0000] <jgraham>
I think "this is all horrible, but that's life" is my new motto

[04:57:40.0000] <annevk>
jgraham: fits you well :-)

[04:57:49.0000] <annevk>
That was a rather fun email to read

[05:00:46.0000] <annevk>
JakeA: so here is an idea

[05:01:05.0000] <annevk>
JakeA: the document/worker creates a ServiceWorkerChannel

[05:01:19.0000] <annevk>
JakeA: in the service worker we expose some kind of uuid per client

[05:01:30.0000] <annevk>
JakeA: then you construct a ClientChannel by passing it that uuid

[05:01:41.0000] <annevk>
JakeA: and then they entangle and things work

[05:02:12.0000] <annevk>
JakeA: we could not even expose a uuid and instead just use the Client objects as parameter, keeping the identification hidden

[05:03:15.0000] <annevk>
JakeA: it has the fancy pansy constructor design to please Domenic and seems easy enough to use

[05:03:55.0000] <annevk>
JakeA: if the SW of a document/worker changes existing ServiceWorkerChannel objects will just get associated anew

[05:04:59.0000] <JakeA>
annevk: can a single ServiceWorkerChannel get messages from multiple serviceworkers?

[05:05:14.0000] <annevk>
JakeA: over time

[05:05:15.0000] <JakeA>
or is it one per sw

[05:05:19.0000] <JakeA>
cool

[05:05:34.0000] <annevk>
JakeA: it's associated with the SW that's associated with the document

[05:05:39.0000] <JakeA>
So I can get messages from my active worker, an installing worker, and even workers from another scope?

[05:05:55.0000] <JakeA>
ohh, so I can't get messages from an installing worker

[05:06:17.0000] <annevk>
we could generalize the design on both sides

[05:06:48.0000] <annevk>
if you pass it a specific worker/client it can only communicate with that worker/client, otherwise all of them?

[05:07:49.0000] <annevk>
however, note that with some clever naming scheme this should be doable on top of BroadcastChannel as well...

[05:09:00.0000] <annevk>
using the client's url as identifier + adding the type of SW (active, installing, any), or leaving them out if you want a more generic BroadcastChannel

[05:09:27.0000] <annevk>
so perhaps BroadcastChannel + library is a better way to go

[05:11:41.0000] <JakeA>
annevk: if the SW has terminated, how does it get broadcastchannel messages?

[05:12:10.0000] <annevk>
ah right, that's why we need something special

[05:12:51.0000] <annevk>
document/worker -> magic -> service worker

[05:13:28.0000] <annevk>
so yeah, for that primitive we need something very much like BroadcastChannel but with the background queueing

[05:14:28.0000] <annevk>
so perhaps ServiceWorkerChannel(optional name) for document/worker and ClientChannel(optional name) for service worker

[05:14:30.0000] <JakeA>
annevk: maybe the idea of stashed ports is useful here https://gist.github.com/mkruisselbrink/536632fcd99d45005064

[05:20:11.0000] <annevk>
JakeA: so I'm trying to imagine the flow of that...

[05:20:32.0000] <JakeA>
annevk: I think this can be done better in similar terms to broadcastchannel

[05:20:39.0000] <annevk>
JakeA: C connects, SW gets handed a port, stashes port, gets shutdown

[05:21:15.0000] <annevk>
JakeA: C posts message, SW is booted, gets C connect event with new port?, gets message about stashed port?

[05:22:13.0000] <annevk>
JakeA: yeah, perhaps we should call it ServiceWorkerChannel on both sides, for the browser it's clear from context what's supposed to happen anyway

[05:22:53.0000] <JakeA>
annevk: C connects, SW gets handed a port, stashes port, gets shutdown. C posts message, SW is booted, SW gets self.onportmessage with the port & message

[05:23:00.0000] <JakeA>
annevk: but I still think there's a simpler model

[05:23:22.0000] <annevk>
JakeA: so if the port is stashed you would not get a connection event but a different one?

[05:24:10.0000] <annevk>
JakeA: it seems nicer if each time you just run the same code (create a ServiceWorkerChannel)

[05:25:04.0000] <JakeA>
annevk: In the stashed model, you don't need a connect event

[05:25:15.0000] <annevk>
JakeA: how do you get handed the port?

[05:26:10.0000] <JakeA>
annevk: in the onportmessage event? It's transferred from the stash

[05:26:35.0000] <annevk>
JakeA: so why do you need to retrieve it from the stash?

[05:26:52.0000] <annevk>
JakeA: seems like you should be able to store and delete them

[05:27:13.0000] <JakeA>
annevk: yeah, you'd need an AsyncPortCollection

[05:27:26.0000] <annevk>
JakeA: I do like this idea as it gives you the entire MessagePort ecosystem

[05:27:42.0000] <JakeA>
annevk: I think I dislike it for that reason :D

[05:27:48.0000] <annevk>
JakeA: everything that people build on top of ports can then automatically be ported to service workers

[05:28:58.0000] <annevk>
JakeA: so yeah, PortCollection has these problems: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23412

[05:29:07.0000] <JakeA>
annevk: also, it doesn't give a way for the SW to contact a particular client. You'd have a collection of ports sure, but it isn't clear which is which

[05:29:24.0000] <annevk>
JakeA: however, PortStorage or some such doesn't really have the same issues I think

[05:29:43.0000] <annevk>
JakeA: we'd put the ports on the client objects and make the client objects live

[05:29:49.0000] <annevk>
JakeA: or some such

[05:29:55.0000] <JakeA>
annevk: yeah, not only that, but if you stash two entangled ports you've got a leak

[05:30:08.0000] <annevk>
JakeA: that could throw

[05:30:59.0000] <annevk>
Yeah I guess you want to store more than just the port, you need some metadata

[05:32:46.0000] <annevk>
I both like and dislike that this is a hard problem

[05:34:56.0000] <annevk>
JakeA: so say in clients ServiceWorker objects are live and in service workers Client objects are life, and both of them expose ports

[05:35:19.0000] <JakeA>
annevk: I'd still like this to be more under-the-hood. Say when a new page/worker is created, it creates a port pair. When the SW gets a client object, client.postMessage goes to port2.postMessage. port1.onmessage proxies to navigator.serviceWorker.onmessage. You could call it onserviceworkermessage is the naming is a problem (since many ports would land

[05:35:20.0000] <JakeA>
messages there)

[05:35:31.0000] <annevk>
JakeA: if you want for a particular port to remain active from the point of the service worker you store it, and then you remove it once you no longer care

[05:35:50.0000] <annevk>
JakeA: once clients are GC'd the corresponding ports in storage can also be GC'd

[05:36:21.0000] <annevk>
JakeA: I think that would work

[05:37:21.0000] <annevk>
JakeA: that doesn't really solve any of the persistency problems, that's sugar we could add later

[05:37:57.0000] <annevk>
(with "I think that would work" I was referring to my proposal)

[05:38:57.0000] <JakeA>
annevk: so, self.clients.getAll().then(c => c[0]) - c[0] has a .port?

[05:39:39.0000] <annevk>
JakeA: if clients become live, I would expect self.clients[0] or some such to work

[05:39:44.0000] <annevk>
JakeA: and yes, it would

[05:40:07.0000] <annevk>
JakeA: but unless you store it, it'll go dead

[05:41:30.0000] <JakeA>
annevk: why do they need to be live? (I'm worried about the overhead of updating those live)

[05:42:53.0000] <annevk>
JakeA: because the ports are live and it would be kind of weird for static objects to point to live ports that need to be === identical

[05:44:50.0000] <JakeA>
annevk: so where would client.port.postMessage land?

[05:45:30.0000] <annevk>
JakeA: navigator.serviceWorker.x.onmessage

[05:46:35.0000] <JakeA>
annevk: where x is a SW instance? So navigator.serviceWorker.controller.onmessage?

[05:47:42.0000] <annevk>
JakeA: yeah

[05:48:33.0000] <annevk>
perhaps the ServiceWorkerChannel idea is not that bad as this does seem rather horrid

[05:48:44.0000] <annevk>
and then have port stashing as a separate feature

[05:49:00.0000] <JakeA>
I think we've happened upon the hardest problem in computer science

[05:50:15.0000] <JakeA>
annevk: but if there's a way for multiple client ports to post message to serviceWorker.onmessage, I think we're getting close to a solution

[05:51:01.0000] <annevk>
no, ports are 1:1

[05:51:03.0000] <JakeA>
annevk: if the stashing is under-the-hood, does client.postMessage work?

[05:51:14.0000] <JakeA>
hm I'm confused

[05:51:15.0000] <annevk>
something like BroadcastChannel can be N:N

[05:52:16.0000] <JakeA>
annevk: I thought you just said clients[0].postMessage and clients[1].postMessage land at navigator.serviceWorker.controller.onmessage

[05:54:06.0000] <annevk>
JakeA: yeah, but those would be distinct channels

[05:54:11.0000] <annevk>
JakeA: one for each client

[05:54:59.0000] <JakeA>
annevk: and something underneath proxies them to the single controller.onmessage?

[06:02:15.0000] <annevk>
I don't know, which is why I suggested that maybe ports were not the best idea and something like BroadcastChannel would be better

[06:04:51.0000] <caitp->
how many SW do you anticipate living together and coordinating together?

[06:08:16.0000] <JakeA>
annevk: So if each page/worker created a BroadcastChannel using a unique id, client.postMessage could broadcast to that channel, navigator.serviceWorker.onmessage could receive it. The ServiceWorker could also create a uid BroadCastchannel to explain how serviceWorkerInstance.postMessage works. The trouble is identifying the source of those messages. Ideally

[06:08:16.0000] <JakeA>
the page wants to get an instance of the SW with the message, and the SW needs a client instance

[06:09:10.0000] <JakeA>
caitp-: serviceworker-to-serviceworker is being looked at by http://mkruisselbrink.github.io/navigator-connect/ - I don't really know a whole lot about it though

[06:10:09.0000] <caitp->
my understanding was that they're sort of expensive, so a single application probably doesn't need to set up a whole bunch of them

[06:10:29.0000] <caitp->
unless the idea is that the facebook api needs their own background thread or something, and all of your different tabs need to talk to it

[06:10:57.0000] <JakeA>
caitp-: that's more of a sharedworker thing I think

[06:11:38.0000] <JakeA>
A serviceworker registration can have 3 serviceworkers active at once, but that's pretty rare. Usually it's only 1.

[06:12:17.0000] <JakeA>
The three are installing (setting itself up to be the next version), waiting (ready to be the next version, but the current version is still in use), and active (the current version)

[06:14:12.0000] <JakeA>
The installing one would be running, as it's setting up caches and such. The waiting version is rarely running, although I guess it'd have to wake up if you did a postMessage to it. The active version wakes up when it needs to receive events, such as fetch, push, message etc

[06:17:40.0000] <annevk>
JakeA: why are you so attached to an existing API?

[06:18:07.0000] <annevk>
JakeA: if we have something like BroadcastChannel that works for service workers, why not let developers create the abstractions?

[06:23:09.0000] <JakeA>
annevk: maybe I'm letting existing things get in the way, but I don't want something more complicated than client[method-to-send-a-message](obj) + window.somewhere.addEventListener('receive-the-message', event => event[way-to-id-the-sender-and-post-a-message-back]) + serviceWorkerInstance[method-to-send-a-message] +

[06:23:09.0000] <JakeA>
self.addEventListener('receive-the-message', event => event[way-to-id-the-sender-and-post-a-message-back])

[06:23:54.0000] <annevk>
what exists?

[06:24:00.0000] <annevk>
we already shipped something?

[06:24:04.0000] <annevk>
:-(

[06:24:13.0000] <JakeA>
huh?

[06:24:38.0000] <annevk>
"letting existing things get in the way"

[06:24:43.0000] <JakeA>
You brought up the existing bit. "why are you so attached to an existing API?"

[06:25:15.0000] <annevk>
Ah yeah, it seems like you have some idea what you want and try to layer anything on top of that idea

[06:25:38.0000] <annevk>
I'd be much more interested in just exposing the primitives that make messaging possible

[06:26:12.0000] <annevk>
It seems like we keep realizing that we're bad at API design so we should let developers do it and just expose the bare minimum, but then we don't really do that...

[06:26:57.0000] <JakeA>
I'm all for exposing primitives but only if it offers something useful & not just overcomplicating

[06:27:56.0000] <annevk>
If it's a primitive it's by definition not complex

[06:28:06.0000] <wanderview>
annevk: am I reading the fetch spec correctly in that Access-Control-Allow-Headers is required? https://fetch.spec.whatwg.org/#cors-preflight-fetch

[06:28:24.0000] <wanderview>
I don't see flickr returning that header... but it seem our fetch() calls go through

[06:28:45.0000] <annevk>
wanderview: that's only used for preflights

[06:28:55.0000] <JakeA>
An API to allow a serviceworker to message a specific client, and allowing a client to message a specific serviceworker doesn't sound like high-level luxury

[06:28:56.0000] <annevk>
wanderview: and only if custom headers are specified

[06:29:15.0000] <wanderview>
annevk: trained-to-thrill uses custom headers... passes an x-cache header or something

[06:29:30.0000] <JakeA>
wanderview: those never go to fetch()

[06:29:49.0000] <JakeA>
The SW stops requests with that header and never passes them to fetch

[06:29:54.0000] <wanderview>
JakeA: I thought I saw it in my network panel last night... I could have been dreaming, though

[06:30:44.0000] <gsnedders>
is there telemetry anywhere for what charset decoders are being used in browsers?

[06:30:52.0000] <JakeA>
wanderview: https://github.com/jakearchibald/trained-to-thrill/blob/master/www/static/js-unmin/sw/index.js#L61

[06:31:11.0000] <annevk>
JakeA: it is a luxury if you add some kind of weird duplication/distribution thing to the mix, rather than keep it 1:1

[06:31:30.0000] <wanderview>
JakeA: oh... I think I saw it in the case where SWs weren't enabled... so a fetch() is not done in that case

[06:31:32.0000] <JakeA>
wanderview: 'accept' is a simple header anyway, so won't trigger preflight

[06:31:44.0000] <wanderview>
yea

[06:31:49.0000] <annevk>
JakeA: the alternative is something like BroadcastChannel with optional scoping

[06:32:46.0000] <JakeA>
wanderview: requests with that 'accept' should only be sent if the page is controlled https://github.com/jakearchibald/trained-to-thrill/blob/master/www/static/js-unmin/index.js#L68

[06:33:13.0000] <gsnedders>
AFAICT, Mozilla doesn't have any telemetry for that, and I get confused looked for stuff in the Google telemetry

[06:33:43.0000] <wanderview>
JakeA: hmm... I probably did something stupid :-)

[06:39:17.0000] <annevk>
JakeA: given that both sides have to cooperate I don't really see the problem with using SWC

[06:39:41.0000] <annevk>
JakeA: e.g. new SWC(url + swType) on both sides gives you quite specific control

[06:40:21.0000] <annevk>
JakeA: you can basically scope the messaging in any way you want, rather than being tied to some specific scenarios we cooked up

[06:41:59.0000] <gsnedders>
hswolff: I presume the DECODER_INITIATED was the best you could do, and actually having what encoding a given page is would be too expensive and too much data?

[06:51:29.0000] <JakeA>
annevk: dumped some requirements at https://github.com/slightlyoff/ServiceWorker/issues/609#issuecomment-74080640

[06:52:47.0000] <gsnedders>
hswolff: sorry, wrong nick!

[06:53:31.0000] <JakeA>
annevk: what is swType?

[07:07:09.0000] <annevk>
JakeA: e.g. "installing" "active"

[07:07:37.0000] <JakeA>
annevk: hmm, so messages get lost if the sw changes state during a conversation?

[07:08:08.0000] <annevk>
JakeA: that depends on the conventions of your messaging strategy

[07:08:13.0000] <annevk>
JakeA: the argument is simply a string

[07:08:34.0000] <annevk>
JakeA: it's up to developers to decide what granularity they need

[07:11:48.0000] <annevk>
Thinking about it some more it's not entirely clear how waking up the service worker would work in a clean way with this proposal

[07:13:25.0000] <annevk>
JakeA: so yeah, maybe I'm coming around to the weird design

[07:14:53.0000] <annevk>
navigator.serviceWorker.onmessage / navigator.serviceWorker[x].postMessage() vs self.onmessage / self.clients.getClients().then((c) => c[0].postMessage())

[07:14:53.0000] <JakeA>
annevk: you'd still need a way to stash/register the channel, and it'd need to be per serviceworker rather than per registration, so different to where push registrations are stored

[07:15:59.0000] <JakeA>
where event.source is the sending client/serviceworker?

[07:16:08.0000] <annevk>
It's not exactly pretty, and I've no idea what the underlying primitives are, but it could be written out in a way that would work

[07:16:33.0000] <annevk>
JakeA: a static copy of it I guess?

[07:16:58.0000] <annevk>
JakeA: would not ===

[07:18:02.0000] <annevk>
JakeA: will try to think about it some more :/

[07:18:36.0000] <JakeA>
annevk: !== is already true of clients and SerivceWorker instances. Clients are already static. ServiceWorker instances are live as they have .status and a statuschange event

[07:20:44.0000] <JakeA>
"!== is already true" urm, by that I mean they're not equal, even if they represent the same SW/client

[07:27:19.0000] <annevk>
JakeA: hmm, it seems weird if serviceworker instances are live that !== would be true

[07:27:45.0000] <annevk>
JakeA: is the spec broadcasting these statuschange events to all copies or some such?

[07:28:34.0000] <JakeA>
annevk: yeah

[07:29:04.0000] <annevk>
it's not exactly live if there's a bunch of copies

[07:29:14.0000] <annevk>
live is what the DOM is like

[07:29:31.0000] <JakeA>
annevk: === means making expandos work across window objects :(

[07:29:34.0000] <annevk>
e.g. <a> being only a single instance ever

[07:29:51.0000] <annevk>
JakeA: uhm you'd create one per window obv

[07:30:15.0000] <annevk>
JakeA: otherwise prototype would already be weird

[07:31:05.0000] <JakeA>
annevk: actually, === is probably useful in this case. if (messageEvent.source === navigator.serviceWorker.controller)

[07:31:25.0000] <annevk>
uhuh, also in the other case though

[07:31:55.0000] <annevk>
you kind of want live Client / SW objects

[07:35:18.0000] <JakeA>
Yeah, there is a lack of consistency there. Live client objects sounds really tough

[07:37:08.0000] <JakeA>
back later, going to try and get some of this talk done…

[07:42:41.0000] <wanderview>
/me is sad "Be my controlled document" won't fit on a candy heart.

[08:16:01.0000] <hswolff>
gsnedders i will treasure the time we had together

[09:24:21.0000] <hsivonen>
ISO-2022-JP, the Russian edition: https://bugzilla.mozilla.org/show_bug.cgi?id=1130533 (KOI8-R)

[09:24:27.0000] <hsivonen>
annevk: ^

[09:25:39.0000] <gsnedders>
hsivonen: I presume the DECODER_INITIATED_* was the best you could do, and actually having what encoding a given page is would be too expensive and too much data?

[09:25:56.0000] <hsivonen>
I need to learn to WONTFIX stuff like that with less debate

[09:26:30.0000] <hsivonen>
gsnedders: I figured that counting pages is less interesting, because people might be loading the same thing over and over

[09:26:51.0000] <hsivonen>
gsnedders: if something isn't used in a session at all, it's a good indication that it doesn't matter

[09:26:54.0000] <hsivonen>
for that user

[09:27:23.0000] <hsivonen>
gsnedders: but when something is used, the number of times it is used doesn't really tell you much beyond needing to keep the functionality

[09:28:03.0000] <annevk>
hsivonen: so we removed it from the menu based on statistics right?

[09:28:31.0000] <hsivonen>
annevk: based on what the Thunderbird defaults were

[09:28:53.0000] <hsivonen>
annevk: i.e. no locale saw the need to default to KOI8-R for outgoing

[09:29:03.0000] <hsivonen>
annevk: and ru-RU even defaulted to UTF-8

[09:29:16.0000] <annevk>
hsivonen: k, it doesn't seem as bad an encoding as iso-2022-jp, but yeah, dunno

[09:29:49.0000] <annevk>
hsivonen: wait, Firefox Nightly does still have this encoding as a preference

[09:29:56.0000] <hsivonen>
well, I'm not a SeaMonkey dev. they can do whatever they like as long as it doesn't affect the UI in mozilla-central

[09:30:08.0000] <hsivonen>
annevk: for the Web, yes

[09:30:19.0000] <hsivonen>
annevk: but there's no UI for choosing KOI8-R for the Web

[09:30:23.0000] <hsivonen>
as a default that is

[09:30:56.0000] <hsivonen>
annevk: sorry. let me try again

[09:31:10.0000] <hsivonen>
annevk: Firefox has this encoding in the menu. but not in the pref panel

[09:31:32.0000] <gsnedders>
hsivonen: ok, just been playing around with faster decoding, and would be interesting to know how many things are decoded with each, but not all too important

[09:31:39.0000] <hsivonen>
"Cyrillic" in the prefs means windows-1251

[09:31:53.0000] <gsnedders>
hsivonen: just trying to use something as a somewhat arbitrary proxy :)

[09:33:46.0000] <hsivonen>
note to self: learn to be less easily trolled into using time to debate people who claim recipients can't deal with UTF-8 yet

[09:34:56.0000] <hsivonen>
btw, if one wants to combine the encoding topic and the EME topic (who doesn't?), just take a look at PlayReady PSSH boxes.

[09:35:15.0000] <hsivonen>
wasting bytes by making every second byte zero

[09:35:18.0000] <hsivonen>
because UTF-16

[09:35:34.0000] <annevk>
heh

[09:35:45.0000] <annevk>
such great hobbies

[09:37:40.0000] <terinjokes>
annevk: i've been thinking on this vacation, wouldn't it be great if maybe, just sometimes, we had other hobbies?

[09:41:11.0000] <annevk>
terinjokes: I know one person that tried and didn't really succeed, although he did later quit his online persona

[09:43:06.0000] <terinjokes>
annevk: I'd argue I haven't succeeded on this vacation either.

[09:43:29.0000] <Ms2ger>
Why do you have an internet connection on vacation?

[09:44:34.0000] <jgraham>
Ooh, is this like a "why did the chicken cross the road" joke?

[09:44:44.0000] <jgraham>
"To get to the other side"?

[09:47:42.0000] <terinjokes>
Ms2ger: I have to book trains and hostels

[15:26:25.0000] <TylerH>
Hey TabAtkins, is this a good place to ask you about  the status of ::before and ::after interactions with replaced elements?

[15:31:22.0000] <TylerH>
Specifically " Note. This specification does not fully define the interaction of :before and :after with replaced elements (such as IMG in HTML). This will be defined in more detail in a future specification. " from http://www.w3.org/TR/CSS21/generate.html#before-after-content (when will the specification define it in more detail?)

[15:34:17.0000] <TabAtkins>
TylerH: Either the Pseudo-Elements spec or the Content spec will define that.  Hasn't been done yet.

[15:49:02.0000] <jgraham>
Hmm, I had to do search and replace on every third <td> element in a table, and I couldn't think of a cleverer way of doing it than n n <space>, and now I have We Will Rock You in my head


2015-02-13
[17:04:20.0000] <GPHemsley>
nn nn nn nn nn nn nn nn nn (alright!)

[20:38:22.0000] <inian>
Hey, Synchronous XHR requests on the main thread got deprecated recently.

[20:38:23.0000] <inian>
 I was using them to analyse JavaScript where some dynamic values were sent to the server and the program execution continued based on the values returned by the server. Of course, this was just to analyse JS and not for a user-facing website. Is there any other alternative for carrying out such analyses where the further program execution depends on the result of the XHR call without a sychronous XHR?

[20:50:56.0000] <caitp>
inian: you can block useful functionality until a promise is fullfilled, for example

[20:51:20.0000] <caitp>
show a loading spinner or splash screen until that happens

[01:25:02.0000] <annevk>
Request.prototype.abort() -- I can think of three states a Request object can be in. 1) Before passed to fetch(). 2) After passed to fetch(). 3) Exposed to SW (similar to before passed to fetch(), but subtly different in state).

[01:25:49.0000] <annevk>
I think only in 2) should it actually do something. Making it work in 3) seems confusing, invoking preventDefault() seems like a better alternative.

[01:25:57.0000] <annevk>
Am I missing something?

[05:47:42.0000] <annevk>
So the problem with articles introducing these application frameworks is that the critique is never really backed up by evidence. E.g. http://calendar.perfplanet.com/2013/diff/ claims "Attaching event listeners to DOM nodes is painfully slow and memory-consuming." as justification for event delegation. Now we want event delegation at some point with native support, but I always thought that was mostly for convenience...

[05:48:49.0000] <annevk>
The recent Flipboard article simply claimed that the DOM was slow. And everyone echoes the sentiment, but it never gets really concrete.

[05:56:05.0000] <caitp->
well, it's not like there aren't aspects of it which are correct

[05:59:33.0000] <caitp->
people touch the DOM, cause unwanted/unexpected layout, hear about the cost of crossing between JS and native code, hear "we can't optimize calls to native code", think about creating a bunch of new event listeners in memory for every important node they care about instead of just one, etc

[05:59:44.0000] <caitp->
it doesn't mean it's all true, but you can see how people come to those conclusions

[06:00:08.0000] <caitp->
then you have people writing 3 line benchmarks to prove their case

[06:00:44.0000] <caitp->
or drawing a correlation between MMR vaccines and autism based on a sampling of 12 kids

[06:01:11.0000] <caitp->
people are funny like that

[06:01:34.0000] <caitp->
preconceived notions, confirmation bias, and a tiny bit of fact

[06:09:20.0000] <annevk>
Sure, but I need the facts :-)

[06:13:17.0000] <gsnedders>
My favourite benchmarks are those where we can LICM the whole benchmark. Why run your benchmark multiple times anyway? That's pointless!

[06:16:16.0000] <annevk>
LICM?

[06:16:25.0000] <Ms2ger>
loop invariant code motion

[06:17:14.0000] <annevk>
ah

[06:17:35.0000] <annevk>
Decided to ask the author: https://twitter.com/annevk/status/566234156754288640

[06:17:56.0000] <annevk>
If native event delegation would be a big help, we should just go ahead and do it

[06:18:35.0000] <wanderview>
annevk: why do we want abort() on Request instead of passing a timeout parameter to fetch()?

[06:20:15.0000] <wanderview>
it just seems like something more related to the actual fetch() operation, and not all the places Request object is used

[06:20:43.0000] <wanderview>
I guess having the abort() on the fetch() returned Promise would be ideal

[06:23:00.0000] <wanderview>
I guess that doesn't exist, though

[06:23:12.0000] <wanderview>
/me reproduces the issue conversation in his head.

[06:25:47.0000] <gsnedders>
annevk: basically JS VMs are getting better and better at entirely optimizing out benchmarks

[07:02:03.0000] <annevk>
/me waits for wanderview to resolve

[07:06:37.0000] <wanderview>
/me aborted.

[07:07:29.0000] <annevk>
hah, that doesn't exist :p

[07:08:34.0000] <annevk>
wanderview: so another idea Hixie had was to have a message channel between the API initiating the request and the FetchEvent in the service worker; that also seems like something you'd put on Request

[07:14:43.0000] <wanderview>
annevk: personally I like defining the timeout as a value that the fetch algorithm interprets instead of an external method called by arbitrary script

[07:15:10.0000] <wanderview>
as the one issue commented pointed out... you really want an inter-packet timeout... not a total request deadline

[07:23:16.0000] <annevk>
wanderview: don't we also want a generic way to abort though?

[07:23:36.0000] <annevk>
wanderview: e.g. if you no longer need something

[07:24:22.0000] <annevk>
wanderview: in any event, even if we don't have abort(), there's still the problem that sometimes we might want methods on Request to proxy somewhere and that falls apart with how fetch() works

[07:32:41.0000] <wanderview>
annevk: I think you need some object representing the fetch operation itself... Request is not that object

[07:32:55.0000] <wanderview>
since it can be used for other things, cloned, etc

[07:33:13.0000] <wanderview>
annevk: can we inherit Promise?

[07:34:26.0000] <annevk>
wanderview: I don't think we want to

[07:34:58.0000] <annevk>
wanderview: if you get declarative constructs around Promise, any subclass of it would be disadvantaged

[07:36:34.0000] <wanderview>
annevk: what about a duck-type compatible object that exposes the underlying promise if needed as .promise?

[07:37:16.0000] <annevk>
wanderview: I don't see how that would be different from a subclass

[07:37:54.0000] <annevk>
wanderview: declarative syntax would still work with the subclass, it's just that the extras are not available (which is why you want to have those elsewhere, not on a subclass)

[07:37:55.0000] <wanderview>
annevk: well... not direct prototype chained...  and gives access to the promise if there is a promise-specific operation to perform

[08:02:52.0000] <wanderview>
annevk: with a simple method like fetch() that returns a promise, though... I don't see where you stick those extras, though

[08:19:04.0000] <annevk>
MikeSmith: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26338 has spam in last comment added

[08:19:46.0000] <annevk>
wanderview: one thing some languages have is apparently that you can go from let x = fetch() to let x, y = fetch()

[08:19:55.0000] <annevk>
wanderview: but that seems unrealistic

[08:20:20.0000] <wanderview>
annevk: isn't es(something) adding de-structuring like that?

[08:20:28.0000] <annevk>
wanderview: that leaves you with the value fetch() does return or whatever you pass to fetch()

[08:20:53.0000] <annevk>
wanderview: yeah, but it would require returning [x, y] which would break existing code

[08:21:05.0000] <annevk>
wanderview: you can't return multiple values

[08:22:16.0000] <annevk>
Also, that doesn't really help with the <img>.request.port.postMessage(...) case

[08:26:30.0000] <annevk>
https://github.com/krisselden/simple-dom is nice

[08:26:45.0000] <annevk>
I wonder why they support comments

[08:37:12.0000] <darobin>
annevk: I suspect they might support comments so that when the simple-dom gets inserted into the real DOM, you can debug and find your kittens

[08:37:34.0000] <darobin>
also, perhaps conditional comments could matter in some cases

[09:22:48.0000] <wanderview>
annevk: could we pass an "abort promise" to fetch()... if it resolves or rejects, then the fetch should abort

[09:29:47.0000] <annevk>
wanderview: that's an interesting idea

[09:30:08.0000] <annevk>
wanderview: how would we solve the messaging use case though?

[09:30:25.0000] <annevk>
wanderview: or modifying the Request post-fetch in some kind of HTTP/2 scenario

[09:30:34.0000] <annevk>
(e.g. changing priority on the fly)

[09:30:37.0000] <wanderview>
annevk: make promisses transferable?  (to be honest I didn't look at the messaging use case"

[09:31:32.0000] <annevk>
wanderview: the messaging use case is primarily about letting an API endpoint (such as <img> or fetch()) communicate with the service worker handling its fetch

[09:32:04.0000] <annevk>
wanderview: by handing the API endpoint and its FetchEvent a port each

[09:32:24.0000] <wanderview>
annevk: that seems orthogonal to aborting a fetch() call?

[09:33:25.0000] <annevk>
wanderview: oh it is, and modification post-fetch is too, but what they have in common is that they need a way to be exposed

[09:34:10.0000] <wanderview>
annevk: the serviceworker script could tie the onmessage event handler to its "abort promise"... although I guess discouraging globals on SWs makes that harder

[09:35:12.0000] <annevk>
I'm not sure how you would tie to that promise to be honest

[09:35:16.0000] <wanderview>
annevk: the onmessage event handler in SW could deliver a message with attributes like fetchevent: { respondedWith: someResponse } or something

[09:35:30.0000] <annevk>
It's a bidirectional communication channel

[09:39:16.0000] <annevk>
Let's start again, these are the use cases I have for Request:

[09:39:21.0000] <annevk>
1) request.abort()

[09:39:39.0000] <annevk>
2) request.port.postMessage(...) / request.port.onmessage = ...

[09:40:04.0000] <annevk>
3) request.changePriority(...) (and similar things, where you want to change something about an ongoing fetch)

[09:41:50.0000] <wanderview>
yea, I don't like any of those on the request object... we really need a handle to an object representing the on-going fetch

[09:42:16.0000] <annevk>
Now an alternative solution for 1) and 3) would be some kind of promise you pass in, but that would not work for HTML: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533 not sure about 2)

[09:42:57.0000] <annevk>
/me wonders if Domenic has any ideas

[09:43:01.0000] <wanderview>
annevk: could we set a "FetchState" object on the request while its in process?

[09:43:19.0000] <Domenic>
that sounds similar to the cancelation token idea C# uses

[09:43:27.0000] <wanderview>
fetch injects the state object onto the request... and then removes it when its no longer being operated on by the fetch

[09:43:51.0000] <Domenic>
(well, the abort promise idea does, I am still reading downward)

[09:44:12.0000] <annevk>
wanderview: you mean we augment it for a short period of time?

[09:44:27.0000] <annevk>
wanderview: why not just have the API there and only enable it while fetch() is ongoing?

[09:44:27.0000] <wanderview>
annevk: yea

[09:45:05.0000] <wanderview>
same effect I think... stateful APIs like this kind of suck for the dev, though... don't they?

[09:45:12.0000] <wanderview>
I mean my idea sucks too

[09:45:41.0000] <annevk>
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0607.html

[09:46:32.0000] <Domenic>
I dunno, maybe we should just solve cancellable promises

[09:46:33.0000] <annevk>
wanderview: it's a bit weird that you cannot reuse the Request during that period of time

[09:46:42.0000] <annevk>
Domenic: that doesn't solve 2/3 though

[09:46:48.0000] <Domenic>
Ah I see

[09:46:57.0000] <annevk>
wanderview: but that's maybe not too bad

[09:47:16.0000] <annevk>
wanderview: but yeah, having some kind of "fetch in progress flag" and exposing that was my idea

[09:50:00.0000] <wanderview>
annevk: what about fetch functions like abortFetch(someRequest)... and does the thing if an active fetch that matches the request is in progress?

[09:51:02.0000] <annevk>
wanderview: that sounds like it requires global lookup

[09:51:33.0000] <annevk>
"is someRequest in your registry?" "oh, please kill it for me"

[09:51:44.0000] <wanderview>
annevk: yes... but the UA could in theory make it happen from any context... vs trying to get the one active Request object to the right place in the dev's code... when we clone it, etc

[09:51:54.0000] <Domenic>
What about fetch({ ..., modifyInProgressFetch(abort, setPriority, port) })

[09:51:59.0000] <annevk>
However, now that you mention it, we might need to keep such a registry, but I'm not sure if we want to expose it

[09:53:02.0000] <annevk>
Domenic: callback I take it? Interesting idea

[09:53:14.0000] <Domenic>
annevk: yeah I guess you'd call back with it immediately

[09:53:24.0000] <Domenic>
kind of like an awkward way of smuggling out multiple return values :-/

[09:53:42.0000] <annevk>
it's the Domenic pattern(tm) https://blog.domenic.me/the-revealing-constructor-pattern/

[09:53:49.0000] <Domenic>
yeppp

[09:54:06.0000] <Domenic>
it seems a bit nicer to put those on Request, I don't really understand the cloning stuff though

[09:54:26.0000] <Domenic>
(or at least it has leaked out of my head since last time)

[09:55:01.0000] <annevk>
currently when you pass a Request to fetch() we transfer the stream (if any) and copy the rest (stripping bits we don't like, such as synchronous flag)

[09:55:21.0000] <annevk>
if the Request did not have a stream you can pass it to fetch() many times

[09:55:25.0000] <annevk>
iirc

[09:56:07.0000] <wanderview>
the callback could be issued on each clone...

[09:56:30.0000] <wanderview>
feels complex to me, though

[09:56:56.0000] <annevk>
I think changing the design of Request to make it aware of it being passed to fetch() would be better

[09:58:32.0000] <annevk>
Oh right, the problem with that is that fetch() only copies from Request what it likes, so we would either have to mutate the Request object, or something else?

[09:58:52.0000] <annevk>
:-(

[10:00:38.0000] <wanderview>
annevk: I still kind of like having fetch stick something on request.. and then script can use that... Request.appendActiveFetch(new ActiveFetch(...))... myRequest.activeFetch.forEach(function(af) { af.abort(); }....

[10:00:53.0000] <wanderview>
when fetch clones a response, it would call appendActiveFetch on the new one Request clone, etc...

[10:03:11.0000] <annevk>
wanderview: I think it would be saner for fetch() to mutate rather than clone and set a flag

[10:12:01.0000] <hemanth_>
does it not makes sense for the arrow function to throw an error on call(), apply(), and bind() as they do not augment the value of `this`?

[10:12:14.0000] <Domenic>
I do agree the cloning seems bad

[10:12:34.0000] <Domenic>
cloning the stream could happen but the entire object seems unnecessary

[10:12:58.0000] <hemanth_>
Some version of FF was throwing an error, the latest one does not

[10:15:46.0000] <wanderview>
well... we can't just clone the body stream until we finish integrating streams into fetch

[10:15:57.0000] <wanderview>
or I guess do some special one off logic in fetch

[10:55:26.0000] <annevk>
wanderview: I'm starting to think that the right thing is to just make Request a one-off everywhere

[10:55:39.0000] <annevk>
wanderview: and if you want to reuse it, better clone it first

[11:05:53.0000] <wanderview>
cd

[11:06:07.0000] <wanderview>
/me can't handle two keyboards...

[11:30:48.0000] <Domenic>
tyoshino________: when do you sleep!? haha

[14:50:43.0000] <Hixie>
anyone know if anyone has looked at how many event listeners typical pages have?


2015-02-14
[17:11:51.0000] <MikeSmith>
annevk: thanks, I've disabled that bugzilla spammer account

[01:20:30.0000] <annevk>
Hixie: seems you can only really tell that using a browser; not aware of any research though it would be interesting

[08:50:14.0000] <pyfisch>
hello, in HTTP/2 are "list headers" usually expressed as multiple headers or as a single header with the values separated by commas? Or is even one option invalid?

[11:05:29.0000] <pyfisch>
again Are in HTTP/2 headers that may have multiple values usually expressed as multiple headers or as a single header with the values separated by commas? Or is even one option invalid?


2015-02-15
[02:06:08.0000] <MikeSmith>
TabAtkins: since css-parse.js no longer provides a parse(...) function I'm trying to figure out what to call instead

[02:06:38.0000] <MikeSmith>
ok I see https://github.com/tabatkins/parse-css#parsing-functions

[02:08:05.0000] <MikeSmith>
TabAtkins: so now I'm wondering, if I'm parsing the contents of a sizes attribute, what should I use

[02:12:27.0000] <MikeSmith>
TabAtkins: OK I see I have my code doing `cssParser.parse("@media " + unparsedSize.toString() + " {}");` so I suppose I need to try parseARule()

[12:31:27.0000] <TabAtkins>
MikeSmith: Ooooof, no, that code's definitely wrong.

[12:31:55.0000] <TabAtkins>
MikeSmith: The spec should describe this, let me dig it up to ensure I'm remembering right.

[12:33:02.0000] <TabAtkins>
MikeSmith: Here you go: https://html.spec.whatwg.org/multipage/embedded-content.html#parse-a-sizes-attribute

[12:33:24.0000] <TabAtkins>
Use parseACommaSeparatedListOfComponentValues() first, then follow the algo for each component of the returned list.

[12:34:02.0000] <TabAtkins>
(Basically just find the last non-ws component value for the size, and if there's anything non-ws preceding it, parse that as a media query.)

[12:36:10.0000] <TabAtkins>
I mean, using that sort of string concat will sorta work, but only because the parser doesn't do any validation anyway, and it'll act incorrectly in the presence of some markup errors (like putting a `{}` in your sizes attr).  It doesn't do any special work for you - it'd just return a CSSRule with a type of "media" and a prelude of the token stream it got

[12:36:10.0000] <TabAtkins>
out of unparsedSize.

[12:38:10.0000] <TabAtkins>
(HTML's lack of deeply nested headings makes large sections like <img>'s really hard to navigate.)

[13:07:48.0000] <Ms2ger>
HTML's lack of deeply nested headings?

[13:07:52.0000] <Ms2ger>
Are you high?

[14:07:05.0000] <TabAtkins>
Ms2ger: IT DOESN'T NEST DEEPLY ENOUGH

[14:14:18.0000] <Ms2ger>
Will it ever?

[14:35:42.0000] <TabAtkins>
Well, for my purposes, if it puts the major <img> algorithms in their own subsections, like the <picture> spec did, that would be enough.

[14:36:31.0000] <TabAtkins>
For some reason <img> thinks it's desperately important to give a heading to every single alt='' use-case, but crams every single other part of its processing model into a single undelineated section.

[14:39:57.0000] <Ms2ger>
Well, ask and you'll probably get some headers :)

[14:43:43.0000] <TabAtkins>
Hixie: ^^^

[14:44:14.0000] <Ms2ger>
He'll probably say "file a bug"

[14:45:11.0000] <TabAtkins>
Heh.

[15:52:25.0000] <MikeSmith>
TabAtkins: yeah that code I cited isn't that part that does the actual checking of the specific requirements for sizes in the HTML source/img spec; instead it's some separate code that runs just to to do an additional syntax check on the <source-size> and <source-size-value> parts.

[15:54:38.0000] <TabAtkins>
MikeSmith: Well, running it through @media doesn't actually help anything; there's no syntax checking above the base statement/rule level.


2015-02-16
[16:00:37.0000] <MikeSmith>
TabAtkins: OK but I couldn't see any other way to force it to check, e.g., "(max-width: 30em) 100vw" on its own (a <source-size-value>) and that wrapping-it-with-@media hack seemed to work

[16:01:38.0000] <TabAtkins>
What are you trying to *get* out of it?  Wrapping it with @media is, I think, solely checking that there's no {} in the value, and that's by accident.  It doesn't do anything else.

[16:02:37.0000] <MikeSmith>
ah OK

[16:04:09.0000] <MikeSmith>
what I think I was trying to get back when I first added it was just for now a way to do an additional syntax check on the <source-size-value> and <source-size> parts

[16:05:27.0000] <TabAtkins>
Okay, well the parser doesn't actually provide any ability to do further syntax checks. ^_^  If what you're asking for isn't one of the entry points, you have to syntax check yourself.

[16:06:55.0000] <MikeSmith>
OK

[16:07:14.0000] <MikeSmith>
TabAtkins: what I aim for longer term is to replace our ad-hoc media="" and sizes="" tokenizer in the validator with your JS tokenizer (via Rhino), because I think that'll be less work than writing a tokenizer in Java myself (and certainly I'm not going to magically have a bunch of time any time soon to write one in Java anyway)

[16:08:09.0000] <MikeSmith>
so I added that code to call your JS tokenizer via Rhino a few months just to see if the basic mechanism would be possible

[16:13:51.0000] <TabAtkins>
Makes sense.  (Though writing a tokenizer to the spec still isn't hard.)

[16:27:03.0000] <MikeSmith>
yeah, just requires more time than I have atm

[16:28:08.0000] <MikeSmith>
anyway, what I have there for that part now "works" to the extent that it's at least not causing any spurious errors to be reported

[16:28:34.0000] <MikeSmith>
after I updated to the latest parse-css.js

[16:28:59.0000] <MikeSmith>
so I'm declaring victory for now

[16:31:26.0000] <MikeSmith>
so I can get a new standalone release out to Jorn Zaefferer for use in the grunt HTML checker he maintains, and out to the Bootstrap project for the thing they use that checks HTML in JSFiddle/JSBin/Codepen links people post in Bootstrap bug reports

[19:45:58.0000] <Hixie>
 TabAtkins: 301 zcorpan

[19:46:09.0000] <Hixie>
well 307 i guess

[22:14:49.0000] <GPHemsley>
/me thinks a wiki should not be the canonical place for the APNG spec: https://wiki.mozilla.org/APNG_Specification

[22:15:31.0000] <tantek>
GPHemsley: wikis are the coolest places for specs, easiest to fix errata ;)

[22:15:46.0000] <GPHemsley>
There is fork development going on here: https://gist.github.com/SoniEx2/c679e771d506210378a5

[22:15:58.0000] <tantek>
wow that URL is so much prettier. not.

[22:16:18.0000] <GPHemsley>
tantek: Perhaps, if your wiki was set up specifically for spec development.

[22:16:27.0000] <GPHemsley>
(which MozillaWiki is not)

[22:16:29.0000] <tantek>
yes, some template work helps with that

[22:16:46.0000] <tantek>
well the github gist wins - it loaded. while the wikimo link is still spinning on a blank page :(

[22:16:55.0000] <GPHemsley>
:(

[22:16:57.0000] <tantek>
oh it finally loaded :(

[22:16:59.0000] <GPHemsley>
That's not good

[22:17:09.0000] <GPHemsley>
Can you check to see what took so long, by any chance?

[22:17:56.0000] <tantek>
looking

[22:18:36.0000] <tantek>
just did a shift reload with the network inspector

[22:18:48.0000] <tantek>
oh hey "Secure Connection Failed"

[22:19:06.0000] <tantek>
trying again

[22:19:39.0000] <tantek>
wow that's a lot of network resources

[22:19:57.0000] <tantek>
still loading

[22:20:56.0000] <tantek>
26 requests, 1531.82KB, 53.39s

[22:21:00.0000] <tantek>
that's pretty pathetic

[22:21:00.0000] <GPHemsley>
Are you logged in?

[22:21:04.0000] <tantek>
yes

[22:21:27.0000] <tantek>
the HTML took 671ms

[22:21:43.0000] <GPHemsley>
hmm... that

[22:21:50.0000] <GPHemsley>
's actually shorter than what I'm seeing

[22:22:05.0000] <tantek>
then so much css and js

[22:22:15.0000] <tantek>
but then the really killers - woffs

[22:22:19.0000] <GPHemsley>
yeah

[22:22:23.0000] <tantek>
designery cheese

[22:22:24.0000] <GPHemsley>
loading the same thing 4 times

[22:22:31.0000] <GPHemsley>
and as text/plain

[22:22:35.0000] <tantek>
maybe I should block all woffs

[22:22:40.0000] <GPHemsley>
I'll be looking into that tomorrow

[22:22:44.0000] <tantek>
Helvetica is good enough :P

[22:23:46.0000] <GPHemsley>
But it seems like the biggest problem is the speed of the server

[22:23:51.0000] <GPHemsley>
These aren't huge files

[22:24:06.0000] <tantek>
goodness sakes, 4618ms to load bg-gradient-sand.png!!!

[22:25:45.0000] <tantek>
9 font files

[22:26:42.0000] <GPHemsley>
But hmm, your speed is definitely much slower than mine

[22:27:17.0000] <GPHemsley>
I get the whole page in ~6 s

[22:27:26.0000] <GPHemsley>
8.45 s this latest time

[22:27:33.0000] <GPHemsley>
and I have 30 requests

[22:27:45.0000] <GPHemsley>
Still, much room for improvement

[22:27:49.0000] <tantek>
I'm on a 1.5/700 ADSL if that makes any difference

[22:27:56.0000] <tantek>
yeah

[22:28:57.0000] <GPHemsley>
https://bugzilla.mozilla.org/show_bug.cgi?id=1133409

[22:32:06.0000] <tantek>
thanks for the heads-up about APNG - captured: https://wiki.mozilla.org/Standards#Orgless_specs

[22:33:20.0000] <tantek>
GPHemsley, FWIW all the microformats and indiewebcamp specs are "living" wiki-developed.

[22:33:57.0000] <GPHemsley>
tantek: Are those wikis shared with other content?

[22:34:15.0000] <GPHemsley>
tantek: And/or have a restricted userbase?

[22:34:57.0000] <tantek>
microformats.org has a fairly strong auto-antispam setup but we get 1-2 a week

[22:35:09.0000] <tantek>
anyone can register, limited editing etc.

[22:35:19.0000] <tantek>
indiewebamp, requires that you naturally log in with your own domain

[22:35:28.0000] <tantek>
which, surprisingly, eliminates all spam

[22:35:39.0000] <tantek>
so no explicit restriction per se

[22:36:04.0000] <tantek>
and yes - shared with much other content - all the background research and brainstorming that goes into the specs

[22:40:33.0000] <GPHemsley>
tantek: But is there any non-spec-related content? What I'm getting at is, MozillaWiki is designed for a bunch of Mozilla-related things; it's not a spec-editing wiki.

[22:40:52.0000] <GPHemsley>
Like, the WHATWG wiki might be a different story

[22:40:55.0000] <tantek>
GPHemsley - sure - there are lists of implementations etc.

[22:41:09.0000] <GPHemsley>
I still consider that spec-related

[22:41:21.0000] <tantek>
microformats is fairly focused around the development of microformats (specs) and everything related - so you're likely right there

[22:41:29.0000] <tantek>
indiewebcamp is broader - it's a community site

[22:41:42.0000] <tantek>
events, how-tos, media lists etc.

[22:41:59.0000] <GPHemsley>
what specs does indiewebcamp handle, anyway?

[22:42:14.0000] <tantek>
but even there, all of those feed into documenting problems people have with existing websites etc. which get turned into experiments, and often converge into specs

[22:43:14.0000] <tantek>
indiewebcamp has a few "core" specs: indieauth, webmention, micropub

[22:43:25.0000] <tantek>
these are broadly implemented building blocks

[22:44:00.0000] <tantek>
and then a few more in development with varying levels of implementation like vouch

[22:44:22.0000] <tantek>
and then a bunch of "mini" specs that build on a bunch of the microformats specs

[22:45:04.0000] <tantek>
though your question makes it clear I should turn the above ^^^ into a wiki page :)

[22:45:12.0000] <tantek>
feel free to join #indiewebcamp for more

[22:58:07.0000] <tantek>
GPHemsley: captured: https://indiewebcamp.com/specifications

[23:01:02.0000] <GPHemsley>
cool

[00:39:14.0000] <annevk>
Mozilla's wiki is used for some B2G specifications

[01:30:45.0000] <annevk>
I would love to have more data around "DOM is slow"

[01:31:55.0000] <annevk>
There are some BlinkOn talks that go into it, and judging from what React is doing it seems somewhat clear what they optimize for, but it would be nice to have more data

[04:10:51.0000] <annevk>
https://speakerdeck.com/vjeux/react-css-in-js is a great set of slides on problems with CSS

[04:19:52.0000] <jgraham>
annevk: So, can I use that talk as evidence next time I hear that web developers aren't asking for encapsulation?

[04:20:24.0000] <annevk>
jgraham: seems like it

[04:20:44.0000] <annevk>
jgraham: though note that shadow DOM didn't really end up working for React either

[04:20:56.0000] <annevk>
jgraham: they eschew most of the DOM

[04:21:31.0000] <jgraham>
Well that might be true, but it's a slightly different issue to "do developers benefit from a situation where they can get actual encapsulation from components"

[04:21:52.0000] <jgraham>
From that talk the answer is clearly "yes"

[04:22:10.0000] <jgraham>
Since FB have also had to hack it on top of CSS

[04:22:12.0000] <annevk>
Yeah, it seems large projects very much need all that

[04:22:30.0000] <annevk>
And I'm sure their "DOM-like components" have it too

[04:24:30.0000] <jgraham>
Indeed

[04:24:55.0000] <jgraham>
I'm not really sure how React works, of if that's something we should be chasing for standardisation

[04:25:29.0000] <jgraham>
I do slightly worry that "DOM is slow" isn't going to get better if it has to embed the possibility of running script every time you parse an element

[04:27:26.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27310 has some debate about standardizing it, but I don't think as-is is going to work

[04:29:10.0000] <annevk>
React seems to use DOM for rendering, but can also use <canvas> or some kind of native API

[04:29:34.0000] <annevk>
But the actual data is kept in some kind of JS structure they refer to as the "virtual DOM"

[04:29:57.0000] <annevk>
https://speakerdeck.com/vjeux/oscon-react-architecture has a bunch of details too

[04:30:50.0000] <annevk>
I didn't know the idea originated from PHP's string concatenation

[04:31:25.0000] <annevk>
Kind of an interesting way for technology to evolve

[04:35:39.0000] <jgraham>
I just read the talk , or at least the parts of if that website actually displayed

[04:36:04.0000] <jgraham>
I expect the history part is writing a good story rather than writing something accurate

[04:36:05.0000] <annevk>
It seemed to have a hard time rendering the O notations

[04:36:19.0000] <jgraham>
Yeah

[04:36:28.0000] <jgraham>
Bugzilla seems to be down

[04:37:28.0000] <annevk>
Well Facebook does use XHP so the history does add up

[04:38:07.0000] <jgraham>
I'm not saying that the slides are a lie, just that the clean evolution from one idea to the next won't be true

[04:38:11.0000] <jgraham>
Anyway, I have heard that Elm is a more extreme/theoretically pure example of the same kind of pattern, with all the immutability required http://elm-lang.org/

[04:38:49.0000] <jgraham>
But I still don't know what there is here that you could take to make the overall web better

[04:40:39.0000] <annevk>
Yeah, I'm trying to figure that out, but it is far from clear

[04:42:11.0000] <annevk>
But it would indeed be good to know before we start invoking more JavaScript during parsing, or add the shadow DOM (whether encapsulated or not)

[05:07:39.0000] <jgraham>
What's the normal way to deal with fallible algorithms in specs? i.e. something that can result either in some data or an error?

[05:10:16.0000] <Ms2ger>
"if it returned an error..."

[05:10:31.0000] <Ms2ger>
I don't know that we really have a good approach yet

[05:11:13.0000] <jgraham>
I feel like what I'm writing is very rust-influenced. I'm not sure that's good

[05:11:44.0000] <jgraham>
(algorithsm that can return objects of type error or type (something))

[05:21:21.0000] <annevk>
jgraham: throw?

[05:21:34.0000] <annevk>
jgraham: but what Ms2ger suggests works too

[05:22:05.0000] <Ms2ger>
jgraham, I think Hixie does that too

[05:23:57.0000] <JakeA>
annevk: fetch(req) already makes the body of the request 'used', what changes does https://github.com/slightlyoff/ServiceWorker/issues/625 change?

[05:24:26.0000] <annevk>
JakeA: if there's no body you can do fetch(req); fetch(req)

[05:24:34.0000] <annevk>
JakeA: I want to disallow that

[05:24:55.0000] <annevk>
JakeA: and instead make a stronger tie between req and its fetching process

[05:26:02.0000] <JakeA>
annevk: Chrome fails on 2 fetches with the same request obj already, even with no body. Sooo… yey?

[05:27:05.0000] <terinjokes>
JakeA: btw, i'm in London this week

[05:28:04.0000] <JakeA>
terinjokes: I'm going to be on talk-writing lockdown all week :( well, if things go well I might be freer later in the week, but I'm already at the panic-poo stage

[05:30:30.0000] <terinjokes>
JakeA: as usual, i have terrible timing.

[05:30:48.0000] <JakeA>
nah, it's me, left things too late

[05:35:23.0000] <wanderview>
JakeA: chrome currently failing on second fetch of same request object is an impl detail, right?  not clear where that is in the spec

[05:35:35.0000] <wanderview>
unless annevk changes it

[05:40:49.0000] <JakeA>
wanderview: I always thought that fetch(req) consumed the request, but you're right, the spec doesn't do that

[05:47:17.0000] <annevk>
JakeA: sounds good I guess

[05:47:54.0000] <annevk>
JakeA: yeah, "consuming" is the idea, though that still means that fetch(string) is inferior, but maybe that's fine for a convenience API

[05:48:20.0000] <annevk>
(and we can always decide to expose a registry-like thing later where fetch(string) can be controlled too)

[05:48:45.0000] <annevk>
wanderview: are there any caches in existence that handle this POST scenario?

[05:48:47.0000] <JakeA>
annevk: I'm happy with that. Although I'm dubious about request.abort() (I assume that's what you're suggesting?)

[05:48:56.0000] <annevk>
JakeA: yes

[05:49:12.0000] <annevk>
JakeA: and request.changePriority(...) and request.port.postMessage(...)

[05:49:53.0000] <wanderview>
annevk: no... Cache spec explicitly forbids POST right now...

[05:50:08.0000] <annevk>
JakeA: if you have a better idea to handle those use cases please mention them in the ticket

[05:51:06.0000] <annevk>
JakeA: for now I think I'll change the model of Request so that the object becomes immutable after passing it to fetch(), then we have more options as to how to handle things

[05:51:27.0000] <annevk>
wanderview: yeah, but outside SW, e.g. the browser cache

[05:51:35.0000] <annevk>
wanderview: it seems like a rather spurious use case

[05:51:59.0000] <annevk>
wanderview: and it would mean that each time you iterate over the cache keys you need to duplicate the body

[05:52:06.0000] <annevk>
wanderview: I don't think that's expected

[05:52:09.0000] <wanderview>
annevk: maybe JakeA knows... his comment that I linked suggested it was expected in the future

[05:52:27.0000] <wanderview>
annevk: thats exactly what we have to do and currently implement

[05:53:33.0000] <annevk>
wanderview: I guess most GET requests don't have a body so it's not too bad, but still...

[05:54:13.0000] <wanderview>
annevk: we don't actually read the body off disk unless someone tries to access the body from script... we just open the fd

[05:54:26.0000] <wanderview>
so I don't think its too painful

[05:57:49.0000] <wanderview>
JakeA: do extendable promises let us do the changePriority and postMessage use cases?

[05:59:56.0000] <JakeA>
annevk: wanderview: removing bodies from cached requests felt arbitrary at the time, but I think it's ok

[06:00:05.0000] <JakeA>
wanderview: nah, we'd still need mutation for that

[06:02:07.0000] <wanderview>
JakeA: it just seems in a number of issues we've come to the conclusion "devs expect to get an object back out that exactly matches what they put in"... for example, not coercing the URL on the response to match the request

[06:02:20.0000] <wanderview>
JakeA: dropping bodies seems to change from that approach

[06:02:39.0000] <wanderview>
/me might be biased since he spent so much time implementing Request bodies. :-)

[06:05:18.0000] <wanderview>
still... simplifying code is good if we can... so lets do it if it makes sense...

[06:27:58.0000] <annevk>
wanderview: JakeA: what happens if you try to cache a request that has a method other than GET?

[06:28:12.0000] <wanderview>
annevk: HEAD works I believe

[06:28:24.0000] <wanderview>
annevk: others reject... I think with a TypeError

[06:28:28.0000] <annevk>
wanderview: both HEAD and GET require that there's no body

[06:28:44.0000] <wanderview>
really?

[06:28:46.0000] <wanderview>
hmm

[06:28:52.0000] <wanderview>
/me is probably an idiot.

[06:29:28.0000] <wanderview>
I thought GET could have a body

[06:29:44.0000] <wanderview>
annevk: the fetch spec disallows this?

[06:29:50.0000] <annevk>
wanderview: see step 21 "If request's method is `GET` or `HEAD`, throw a TypeError. "

[06:30:23.0000] <wanderview>
annevk: where?

[06:30:34.0000] <annevk>
wanderview: https://fetch.spec.whatwg.org/#dom-request

[06:30:54.0000] <annevk>
wanderview: fairly recent addition: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27846

[06:31:04.0000] <wanderview>
annevk: ah... I feel less bad then

[06:31:14.0000] <annevk>
wanderview: I feel bad that you implemented support for bodies :-(

[06:31:44.0000] <annevk>
wanderview: JakeA: so perhaps for now this is not a problem

[06:31:46.0000] <wanderview>
annevk: it was mostly boilerplate... but I'd want to be quite certain we will never support bodies on requests before I remove it

[06:32:46.0000] <wanderview>
annevk: that also means JakeA can remove all the request.clone() methods from here and other docs: http://jakearchibald.com/2014/offline-cookbook/

[06:33:03.0000] <wanderview>
well, once we actually implement that check

[06:37:11.0000] <wanderview>
annevk: oh... nsm already fixed it for us... I wonder if blink is aware of that spec change

[06:38:16.0000] <JakeA>
sorry, got caught up in something. *reads back*

[06:39:01.0000] <JakeA>
/me giggles at the idea of the cache "dropping bodies". It's a real badass.

[06:40:10.0000] <wanderview>
https://www.youtube.com/watch?v=grbSQ6O6kbs

[06:43:36.0000] <JakeA>
wanderview: ah, sorry, the reason POST is blocked from the cache was to avoid the body storage stuff. But yeah, we should be able to drop those .clones

[06:43:50.0000] <JakeA>
(once implementations update, if they need to)

[06:44:35.0000] <wanderview>
well, until that recent change in fetch spec, GET Request could synthetically be created with a body

[06:46:26.0000] <annevk>
I guess Chrome didn't really read the spec...

[06:46:48.0000] <wanderview>
annevk: what do you mean?

[06:47:09.0000] <annevk>
wanderview: from JakeA's comment it sounds like they assumed an invariant around GET/HEAD that wasn't actually there

[06:47:11.0000] <wanderview>
oh... not reusable Request objects

[06:47:19.0000] <wanderview>
oh

[06:48:00.0000] <annevk>
"the reason POST is blocked from the cache was to avoid the body storage stuff" means GET/HEAD having a body wasn't considered

[06:48:22.0000] <wanderview>
ah

[06:48:31.0000] <wanderview>
/me goes for more coffee...

[06:49:01.0000] <JakeA>
annevk: I thought you said it couldn't have a body?

[06:49:24.0000] <annevk>
JakeA: since January 17

[06:49:33.0000] <JakeA>
best date ever

[06:50:24.0000] <JakeA>
I guess we should reopen https://github.com/slightlyoff/ServiceWorker/issues/550 then

[06:50:26.0000] <annevk>
(not JakeA's b-day in case you were wondering)

[06:51:10.0000] <annevk>
JakeA: yeah, GET/HEAD Request objects can be easily reused

[06:51:17.0000] <annevk>
JakeA: and if that's all the cache needs...

[06:55:21.0000] <JakeA>
annevk: so, in summary, fetch() will always "use up" requests, cache.put(req, res) will use up the response but not the request

[06:55:26.0000] <JakeA>
Is that correct?

[06:55:55.0000] <annevk>
JakeA: given the above invariants, yes

[06:56:45.0000] <annevk>
JakeA: though I wouldn't call it "use up" for fetch(); it marks it immutable, but it's still usable for post-fetch purposes, such as abort or messaging with the service worker event responsible for handling it

[06:56:50.0000] <JakeA>
annevk: and .clone() remains a way to use a request twice, as long as it's called before the request is used up

[06:57:10.0000] <JakeA>
true

[06:57:11.0000] <annevk>
.clone() is a way to reuse a request/response that has a body

[06:58:12.0000] <JakeA>
annevk: var r = new Request('/'); var r2 = r.clone(); fetch(r); fetch(r2); // does this work?

[06:58:30.0000] <annevk>
JakeA: yeah, should

[06:58:45.0000] <annevk>
r and r2 will share nothing

[06:58:52.0000] <JakeA>
annevk: ok, so cloning is also useful for requests without bodies

[06:58:57.0000] <annevk>
fair

[07:02:03.0000] <wanderview>
annevk: what are you proposing should happen in this case? cache.put(req, response); req.abort();

[07:02:25.0000] <wanderview>
I bet devs will expect it to abort the put()

[07:03:07.0000] <wanderview>
does this mean every API taking a Request must now be abortable?

[07:03:14.0000] <JakeA>
annevk: Should new Request("/", {body: 'BAM'}) throw?

[07:03:33.0000] <annevk>
JakeA: yeah that would throw

[07:04:13.0000] <annevk>
JakeA: we could make method defaulting conditional (GET when no body is passed, POST when a body is passed) I suppose

[07:05:07.0000] <JakeA>
annevk: ah, sorry, that is in the spec already. Do I need cache.put to throw if the request has a body? Is there any way that can happen?

[07:05:19.0000] <JakeA>
annevk: nah, I think explicit method is fine here

[07:05:23.0000] <annevk>
wanderview: not sure, probably not, could be a reason to consider RequestKey...

[07:05:41.0000] <JakeA>
annevk: wanderview: Or abortable promises :D

[07:05:52.0000] <annevk>
JakeA: request can't have a body if method is either GET/HEAD

[07:06:13.0000] <annevk>
JakeA: abortable promises don't gel with declarative promises

[07:06:21.0000] <wanderview>
JakeA: well... same confusion with the other methods... Cache.put(req, res); req.changePriority();  // wtf does this do?

[07:07:05.0000] <wanderview>
/me wonders how many years it will take before he fully understands all the terminology used in this channel.

[07:07:07.0000] <annevk>
wanderview: we'd probably make it throw or a no-op if Request isn't in the right state

[07:07:28.0000] <JakeA>
wanderview: I guess .put should mark the request as immutab… oh shit we're back here

[07:07:30.0000] <annevk>
wanderview: terminology changes too often :-(

[07:08:34.0000] <wanderview>
yea... I don't like putting this stuff on Request... it goes from being a simple struct with a stream to being this stateful handle thing... which I think makes it a lot harder to understand

[07:09:12.0000] <wanderview>
why do I have to clone() the Request? because there are these methods on it that I don't use but might want to so I can't reuse the Request in another fetch?

[07:09:38.0000] <wanderview>
I guess I'd be interested to hear what web devs think

[07:09:39.0000] <annevk>
wanderview: you could fetch(req.url, req) to cheat :p

[07:11:00.0000] <JakeA>
wanderview: I've seen people expect to be able to add/modify headers as the request passes through the fetch event

[07:11:24.0000] <annevk>
JakeA: that's very different

[07:11:33.0000] <wanderview>
JakeA: you mean and then do respondWith(null)?

[07:11:45.0000] <wanderview>
or default or whatever it is

[07:11:45.0000] <JakeA>
wanderview: well, not call respondWith at all

[07:12:02.0000] <JakeA>
I dunno if we want that to work, but I've seen it

[07:12:19.0000] <annevk>
I think we might, but it's a very different use case from changePriority() as I pointed out in the issue

[07:12:44.0000] <wanderview>
JakeA: I think thats just an argument for https://github.com/slightlyoff/ServiceWorker/issues/607

[07:13:05.0000] <wanderview>
sorry... wrong issue

[07:13:10.0000] <wanderview>
I meant removing event.default()

[07:13:42.0000] <wanderview>
oh... that is the right issue

[07:14:18.0000] <JakeA>
I still think we really want fetch() to return something more than a promise, something that represents an active request

[07:14:29.0000] <JakeA>
But I sort-of get why we can't have that

[07:14:32.0000] <wanderview>
JakeA: yea... I agree

[07:15:50.0000] <JakeA>
request.something() could start the request and return a richer object, with the promise hanging of .ready or something

[07:15:53.0000] <annevk>
My proposal is that we make Request immutable for now when passed to fetch(). This roughly matches Chrome.

[07:16:15.0000] <annevk>
That buys us some breathing room to consider how to handle abort() et al for a month or so.

[07:16:32.0000] <annevk>
Or longer if we think something might change...

[07:17:05.0000] <wanderview>
JakeA: request.something() instead of a fetch()?  why not just controlledFetch() or one of the options I posted in the issue?

[07:18:05.0000] <JakeA>
annevk: That works for me. I guess cache.put should do the same

[07:18:46.0000] <JakeA>
wanderview: that works too. Ughghghghg but it's all worse than var activeRequest = fetch(req); activeRequest.abort();

[07:18:59.0000] <wanderview>
yes

[07:19:58.0000] <annevk>
wanderview: JakeA: I'm proposing immutable for now since it seems likely that any alternative will take us a bit longer to settle on

[07:20:11.0000] <JakeA>
agreed

[07:20:38.0000] <wanderview>
ok

[07:23:17.0000] <JakeA>
annevk: Do you know the status of promise-extending? I guess the problem is fetch(req).then(r => r.json()), how the new promise retains the link to the in-flight request. Am I right?

[07:24:48.0000] <JakeA>
AFAIK it just does currentPromise.contructor.resolve(newPromise), so you'd keep the prototype methods, but lose state like the request

[07:33:27.0000] <annevk>
JakeA: the main problem is async/await I think

[07:33:35.0000] <annevk>
JakeA: just doesn't make much sense with those around

[07:34:18.0000] <annevk>
My solution for Request and fetch() isn't great...

[07:34:38.0000] <annevk>
E.g. what happens with fetch(req, someOverrides)?

[07:35:11.0000] <annevk>
Does req get modified?

[08:02:50.0000] <annevk>
JakeA: wanderview: created https://gist.github.com/annevk/56e97115f2c9c2e90c23

[08:02:58.0000] <annevk>
JakeA: wanderview: has an overview of what we discussed

[08:16:41.0000] <JakeA>
annevk: that captures it. I'm keen to know more about the promise issues, I can't see how it causes issues with async/await. Guess Domenic knows?

[08:17:13.0000] <annevk>
JakeA: well async/await abstracts out the promise

[08:17:33.0000] <annevk>
JakeA: if you then start hanging things of it, you still need the object which is kind annoying

[08:18:46.0000] <JakeA>
annevk: It abstracts the completion of the promise. If you want concurrency you still end up with the promise objects, either var p1 = thing(); var p2 = otherThing(); await p1; await p2; or await Promise.all([thing(), otherThing()])

[08:18:51.0000] <annevk>
JakeA: instead of await fetch() you get var r = fetch(); await r;

[08:19:27.0000] <JakeA>
fetch is one of the things that really benefits from concurrency

[08:19:48.0000] <annevk>
true true

[08:19:56.0000] <annevk>
would be interesting to hear what Domenic thinks

[08:20:25.0000] <annevk>
perhaps a subclass of a promise is less bad than I thought it would be

[08:20:59.0000] <annevk>
I think we might still want to make a few tweaks to how fetch(req) works though

[08:21:43.0000] <annevk>
e.g. if you get a modified Request it would be kind of nice to be able to inspect that, perhaps it should still be reusable, but at least the object should represent its "clipped" state

[08:23:15.0000] <JakeA>
I think the problem is with var p = fetch(req).then(doSomeOtherStuff)

[08:23:34.0000] <JakeA>
As in, how p retains the .abort() method

[08:23:49.0000] <annevk>
Retains?

[08:24:35.0000] <JakeA>
annevk: I believe new promises are created using the constructor or the original promise

[08:24:48.0000] <JakeA>
(I could be outdated or plain wrong)

[08:24:51.0000] <annevk>
You mean of?

[08:24:58.0000] <JakeA>
yeah sorry

[08:25:06.0000] <annevk>
How would that create a subclass?

[08:25:25.0000] <JakeA>
fetch(req).then(doSomeOtherStuff) would have .abort, but Promise.resolve(fetch(req)) would not

[08:25:31.0000] <wanderview>
JakeA: annevk: chrome still has fetch() behind an experimental flag, right?  do we have to maintain backward compat here or can we break compat to get a better API for the long term?

[08:25:55.0000] <Ms2ger>
What's the point of a pref if you can't break stuff?

[08:26:13.0000] <annevk>
JakeA: reading http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-constructor it seems like a subclass is fine

[08:26:31.0000] <annevk>
JakeA: oh you mean forwarding

[08:27:50.0000] <annevk>
JakeA: SpeciesConstructor in http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise.prototype.then makes me think that then() forwards

[08:28:12.0000] <wanderview>
personally I think we should just consider changing it to fetch().reponse().then(function (response) { } );... I guess unless promise extension works out

[08:28:13.0000] <annevk>
JakeA: resolve does not...

[08:28:31.0000] <annevk>
JakeA: but you could do FetchPromise.resolve() presumably...

[08:29:31.0000] <annevk>
wanderview: boilerplate :-(

[08:29:49.0000] <JakeA>
annevk: I hadn't seen the @@species stuff. But yeah, think it works the same way. So I guess each fetch promise would have to define an instance @@species to retain its link to the original request?

[08:29:58.0000] <wanderview>
annevk: better than magic, implicit state on Request IMO

[08:30:32.0000] <annevk>
JakeA: something like that

[08:31:02.0000] <wanderview>
and the difference between fetch().then() and fetch().response().then() is 12 characters

[08:31:08.0000] <annevk>
I'm warming up to the subclass idea

[08:31:15.0000] <wanderview>
ok

[08:31:37.0000] <annevk>
wanderview: I think fetch().ready.then(res) {} would be slightly better if we wanted to go down that route

[08:31:55.0000] <wanderview>
ok

[08:32:16.0000] <annevk>
wanderview: and perhaps move the text() methods and such on that control object too

[08:32:42.0000] <wanderview>
annevk: uh... no?  Cache.match() returns Response objects that need text()

[08:33:03.0000] <annevk>
ah yes

[08:40:53.0000] <wanderview>
annevk: added fetch().ready.then() to your gist

[08:46:27.0000] <annevk>
wanderview: ta

[08:52:12.0000] <annevk>
https://twitter.com/thebabydino/status/567226220249886721 is pretty cool

[08:52:22.0000] <annevk>
I wish the CSS WG would standardize the psuedo-elements already

[08:53:55.0000] <JakeA>
the use of /deep/ and background-size for the selected-so-far bit of the track is really smart

[08:54:29.0000] <annevk>
That use of /deep/ should not actually work

[08:54:32.0000] <JakeA>
I gave up styling range for https://jakearchibald.github.io/svgomg/. I just used a load of divs & clickjacked a real range

[08:54:52.0000] <JakeA>
hah ok. I don't know that much about shadow dom

[09:30:25.0000] <wanderview>
is there anything in the SW spec that prevents multiple fetch events from being triggered for the same URL at the same time?  I mean... second event while still waiting for first event to resolve its respondWith() promise

[09:36:39.0000] <annevk>
wanderview: why would we prevent that?

[09:37:51.0000] <annevk>
wanderview: is this about e.g. the image cache?

[09:48:41.0000] <JakeA>
wanderview: as far as I know, browsers don't have a good answer for this with the http cache either

[09:52:30.0000] <wanderview>
annevk: JakeA: I don't think we should do it... was just wondering as I'm trying to track down an issue in the gecko implementation (https://bugzilla.mozilla.org/show_bug.cgi?id=1130803)

[09:52:52.0000] <annevk>
wanderview: it's still a bit unclear to me what the problem is

[09:53:10.0000] <annevk>
wanderview: if the problem is combining fetches, we should only do that in the network layer

[09:53:14.0000] <wanderview>
annevk: same here :-)  I was just theorizing

[09:53:42.0000] <annevk>
wanderview: I guess I'll try to clarify that part of Fetch tomorrow by creating a section dedicated to the network part

[10:34:16.0000] <wanderview>
is it just me, or is this JakeA's twin (based purely on twitter avatar)? https://twitter.com/m_gol vs https://twitter.com/jaffathecake

[10:34:57.0000] <wanderview>
/me keeps getting them confused in his twitter feed.

[10:35:32.0000] <JakeA>
wanderview: haha there is *some* similarity I think

[10:36:05.0000] <wanderview>
it could just be all Europeans look alike to dumb Americans

[10:36:25.0000] <JakeA>
haha

[10:37:40.0000] <wanderview>
/me is slowly going insane from tracing the gecko network stack.


2015-02-17
[16:36:54.0000] <MikeSmith>
heycam: if the dev.w3.org URL that's slow or unresponsive is under http://dev.w3.org/csswg/ or http://dev.w3.org/fxtf/ it's being rewritten to http://drafts.csswg.org/ so any problems with it being unresponsive or loading slowly would likley be due to drafts.w3.org instead of dev.w3.org itself

[16:37:38.0000] <heycam>
MikeSmith, I see. thanks; will ping plinss in the future about that.

[16:37:47.0000] <MikeSmith>
k

[16:38:42.0000] <MikeSmith>
that said though, there have been times in the past when crawlers hit dev.w3.org and cause it to become unresponsive but I think these days the rate-limiting setup that the systeam has there should prevent that from happening

[16:41:52.0000] <heycam>
ok

[17:36:47.0000] <_2_daychelin>
Hola

[17:36:48.0000] <botie1>
salut, _2_daychelin

[02:12:52.0000] <Ms2ger>
MikeSmith, you have an SGML book behind your desk?

[02:14:54.0000] <zcorpan>
Ms2ger: don't you?

[02:15:13.0000] <Ms2ger>
/me double-checks

[02:15:18.0000] <Ms2ger>
No

[02:15:27.0000] <zcorpan>
handy to look up how parameter entities in the external subset work

[02:16:23.0000] <zcorpan>
or how to tweak the SHORTTAG feature

[02:17:13.0000] <zcorpan>
ain't that right, MikeSmith?

[02:19:09.0000] <MikeSmith>
zcorpan: You know me too well

[02:20:12.0000] <MikeSmith>
/me orders an SGML book to send Ms2ger for his bookshelf

[02:25:18.0000] <Ms2ger>
Oh, I needed a monitor stand :)

[02:30:46.0000] <jgraham>
How are we all looking behind MikeSmith's desk? Has he decided to supplement his salary by becoming a camboy?

[02:34:49.0000] <zcorpan>
jgraham: Naoko Smith leaked a picture on the twitters

[02:39:47.0000] <zcorpan>
promise experts, does http://www.w3.org/2009/dap/track/issues/166 make sense?

[02:42:43.0000] <Ms2ger>
If so, it should probably be an attribute

[03:50:12.0000] <annevk>
Ms2ger: it should, but they probably don't want to expose that on navigator as such due to people enumerating the properties of the object

[03:50:17.0000] <annevk>
Ms2ger: see also getGamepads()

[04:14:39.0000] <Ms2ger>
Does https://html.spec.whatwg.org/multipage/infrastructure.html#root-element allow the "root element" of a node to not be an element?

[04:17:11.0000] <annevk>
Ms2ger: seems like it

[04:18:05.0000] <Ms2ger>
/me files a bug

[06:03:26.0000] <zcorpan>
what is the situation for high-resolution backing store for canvas? i'm having trouble finding relevant things in the spec

[06:37:33.0000] <annevk>
zcorpan: didn't we give up?

[06:39:09.0000] <annevk>
zcorpan: https://html5.org/r/8397 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=24301

[06:56:49.0000] <zcorpan>
annevk: thx

[07:15:57.0000] <wanderview>
/me enables cloudflare to get https on his github.io blog.

[08:16:57.0000] <gsnedders>
<b><b><b><b>x</b></b></b></b>y — what's the parent of the y?

[08:17:43.0000] <Ms2ger>
The pa- Oh wait, AAA

[08:23:05.0000] <jgraham>
gsnedders: The parent of the outermost <b>

[08:28:43.0000] <gsnedders>
jgraham: (that's the whole document, so that'd be body)

[08:28:59.0000] <gsnedders>
(this is all about how Noah's Ark effects it)

[08:30:00.0000] <jgraham>
*affects

[08:30:03.0000] <gsnedders>
(I have someone claiming it sohuld end up as the child of the outermost <b>, and I'm pretty sure they're wrong)

[08:30:27.0000] <jgraham>
Yes, try it in any browser :p

[08:30:29.0000] <gsnedders>
jgraham: can I take the descriptive view that both words are synonymous nowadays? :P

[08:30:36.0000] <jgraham>
gsnedders: No

[08:30:47.0000] <jgraham>
If they were I wouldn't have corrected you :p

[08:32:40.0000] <Ms2ger>
Why would you aks such a thing?

[09:05:40.0000] <wanderview>
Domenic: do you use cloudflare flexible ssl or full ssl with your github.io page?

[09:05:49.0000] <Domenic>
wanderview: flexible SSL

[09:05:58.0000] <wanderview>
k

[09:06:14.0000] <wanderview>
seems like full ssl should be possible since subdomain.github.io supports https

[09:50:53.0000] <JakeA>
annevk: Chrome are going to use https://github.com/slightlyoff/ServiceWorker/issues/609#issuecomment-74714928 as a way to progress with postMessage, let me know if I got it wrong

[09:51:23.0000] <annevk>
JakeA: "We're in agreement"?

[09:51:56.0000] <JakeA>
annevk: I thought you said you were happy with that model now?

[09:52:01.0000] <JakeA>
(I'll change it if not)

[09:53:12.0000] <annevk>
JakeA: well, I think after I said that I posted that comment with some other considerations

[09:53:32.0000] <annevk>
JakeA: I'd like to understand why we still think that ServiceWorker and Client having different lifetime models is a good idea

[09:58:17.0000] <TabAtkins>
zcorpan: Re: battery promise, is the promise solely used to gate the battery access behind an async wall?  That is, it'll generally be perma-fulfilled?

[09:59:34.0000] <zcorpan>
TabAtkins: i don't know, haven't read the spec. this just appeared in my critic inbox

[10:00:47.0000] <JakeA>
annevk: this is the reason clients are snapshots https://github.com/slightlyoff/ServiceWorker/issues/588#issuecomment-66985639 - if each property is behind a promise, it's going to be unmanageable

[10:03:09.0000] <JakeA>
annevk: regardless, I'm not sure what dynamic clients buys us in terms of postMessage

[10:05:49.0000] <annevk>
JakeA: well e.g. === checks

[10:06:09.0000] <annevk>
JakeA: if you keep getting copies of Client objects, it's somewhat annoying

[10:06:24.0000] <annevk>
JakeA: and will be impossible to tell two Gmail windows aparts

[10:08:46.0000] <JakeA>
annevk: I think it's worthwhile looking at that, but this feels separate to where client.postMessage and serviceWorker.postMessage land

[10:10:33.0000] <annevk>
JakeA: well when live it would mean onmessage could be elsewhere

[10:10:40.0000] <annevk>
JakeA: as I suggested in that comment

[10:13:50.0000] <JakeA>
annevk: So function onMessage() {...} clients.forEach(client => client.onmessage = onMessage) would become SW boilerplate?

[10:15:18.0000] <annevk>
we could make the comment bubble to self.clients

[10:15:43.0000] <annevk>
s/comment/event/

[10:23:33.0000] <JakeA>
annevk: that makes iterating through clients really tough when it comes to selecting one to potentially focus / postMessage. Also, serviceWorkerInstance.postMessage going to self.onmessage fits in well with the dedicated worker model. I realise that it isn't 1:1 like dedicated worker, but I don't think that's an issue when it comes to developers using the

[10:23:34.0000] <JakeA>
API

[10:24:42.0000] <annevk>
JakeA: why does it make iteration tough?

[10:25:20.0000] <JakeA>
annevk: See https://github.com/slightlyoff/ServiceWorker/issues/588#issuecomment-66985639, now imagine each state property was behind a promise

[10:27:09.0000] <annevk>
JakeA: yeah, if they were actually live I'd imagine we'd update state based on events

[10:27:15.0000] <annevk>
JakeA: similar to the other side

[10:28:07.0000] <JakeA>
annevk: would you still have the client getter behind a promise? Means that those objects aren't always there to have to update

[10:41:25.0000] <annevk>
JakeA: that seems like an optimization the UA could make

[11:09:46.0000] <Domenic>
annevk: CORS pinning++

[13:29:59.0000] <smaug____>
hmm, can <embed> load web pages or only <object>

[13:30:59.0000] <smaug____>
looks like it can


2015-02-18
[19:41:25.0000] <MikeSmith>
HTML parsers have to all be taught about the `integrity` attribute? https://bugzilla.mozilla.org/show_bug.cgi?id=1100206

[19:49:22.0000] <roc>
MikeSmith: I think that's just an optimization.

[19:52:54.0000] <MikeSmith>
roc: ah ok

[22:15:48.0000] <MikeSmith>
hsivonen: minor FYI https://github.com/validator/validator/commit/4fed5654f831bd9b4135cf157997c8413aaededa

[22:17:46.0000] <MikeSmith>
hsivonen: was doing housekeeping just now (removing executable bit on files per fantasai's e-mail ping) and remembered that VerifierServlet.policy file was still hanging around. Of course feel free to restore it if you actually need it in the repo.

[22:24:39.0000] <MikeSmith>
hsivonen: another minor housekeeping thing when you have a chance - https://github.com/validator/validator/issues/36

[22:25:18.0000] <MikeSmith>
about whether it's ok to `git rm -r research-src` at this point

[23:53:36.0000] <MikeSmith>
zcorpan: Robin and I may be visiting Lund May 3-4 or May 8-9

[23:53:52.0000] <MikeSmith>
but I see now that's not terrifically close to where you are

[23:55:37.0000] <zcorpan>
MikeSmith: cool. yeah it's 5h car ride

[00:42:28.0000] <annevk>
JakeA: how realistic is the podcast service worker example if you can't actually fetch episode information from the target domain?

[04:57:00.0000] <annevk>
wanderview: I'm starting to really like this FetchPromise idea

[04:57:37.0000] <annevk>
wanderview: currently https://fetch.spec.whatwg.org/#concept-request has some bookkeeping details such as "redirect count" and "response tainting"

[04:57:51.0000] <annevk>
wanderview: they would fit much better on a "fetch status object"

[04:58:52.0000] <annevk>
wanderview: could probably also use that to maintain the current URL, rather than mutate request's url as we go...

[06:50:50.0000] <wanderview>
annevk: sounds good to me

[06:51:25.0000] <wanderview>
I think its great the promise extension is a feasible approach to take

[08:23:12.0000] <Domenic>
annevk: what's the plan for cancellation/abort/terminate? Just come up with ad-hoc fetch-only semantics under the name terminate(), then maybe insert CancellablePromise in between the prototype chain later and get a cancel() method?

[08:23:48.0000] <annevk>
Domenic: that's a plan I had if we don't want to wait for CancelablePromise

[08:24:01.0000] <Domenic>
yeah, seems OK

[08:24:11.0000] <annevk>
Domenic: and might make sense given that terminate() is really about terminating the network connection (which also affects the eventual stream)

[08:24:38.0000] <Domenic>
right, so it would have an effect on fulfilled FetchPromises too

[08:25:00.0000] <Domenic>
Still unsure whether it should leave the promise forever-pending, or should reject it

[08:26:29.0000] <annevk>
Domenic: I was going for reject

[08:27:20.0000] <annevk>
Domenic: that happens when something is wrong with the network now

[08:27:55.0000] <annevk>
Domenic: also, forever-pending would require a timeout wrapper which seems unfortunate

[08:27:58.0000] <Domenic>
right. some of the feedback we've gotten on promise-cancellation = rejection has been that that forces people to insert `if (e instanceof Cancellation) { return; }` into the top of every failure handler

[08:28:08.0000] <Domenic>
I don't follow on the timeout wrapper?

[08:28:40.0000] <annevk>
Domenic: forever pending means that callbacks are never invoked

[08:28:52.0000] <annevk>
Domenic: oh, that's interesting

[08:29:12.0000] <Domenic>
yes, which is often what is desired

[08:29:14.0000] <annevk>
Domenic: thanks, that makes it indeed not so clear cut

[08:29:34.0000] <Domenic>
e.g. error handler = show error dialog to user, or do a retry

[08:29:58.0000] <annevk>
Domenic: what if we offer terminate({rejectWith:...})

[08:30:11.0000] <annevk>
when omitted doesn't reject

[08:30:13.0000] <Domenic>
hmm very interesting

[09:30:00.0000] <jtcranmer>
any particular reason why fetch() doesn't support some form of aborting a network request?

[09:30:41.0000] <annevk>
jtcranmer: see logs, not sure about exact API yet

[09:32:39.0000] <jtcranmer>
ah, so I see

[09:32:42.0000] <jtcranmer>
tyvm

[09:51:35.0000] <TabAtkins>
annevk, Domenic: I like the idea of terminating a promise with an option to keep it pending or rejected.  Nicely separates out the concerns.

[09:52:06.0000] <Domenic>
TabAtkins: yeah it is nice and flexible. Trying to think of when I would use the rejectWith option though

[09:52:23.0000] <TabAtkins>
In a promise combinator?

[09:52:38.0000] <Domenic>
Hmm yeah maybe

[09:54:18.0000] <annevk>
Admittedly it is fairly hard to imagine a scenario where network failure and intentionally causing network failure require the same code path

[09:54:56.0000] <annevk>
So far all I've come up with is showing some generic error message "Your network connections are not up to par!"

[10:05:16.0000] <jtcranmer>
the use case for terminating network-related promises that is most evident is "user hits the cancel button"

[10:05:41.0000] <jtcranmer>
potentially there's clean-up related actions

[10:06:09.0000] <jtcranmer>
but the ultimate .catch() is likely to be some sort of error dialog which you'd want to supress

[10:18:37.0000] <annevk>
I think another compelling argument for forever-pending is that in the case of the promise already being resolved and the stream being canceled due to lack of network activity you cannot use the promise rejection code path either.

[10:26:10.0000] <annevk>
/me reads through https://github.com/kriskowal/q/issues/64

[10:30:57.0000] <annevk>
So Q doesn't have it due to multiple clients of a single promise potentially getting confused

[10:33:01.0000] <annevk>
/me finds https://github.com/promises-aplus/cancellation-spec/issues/6 next

[10:33:39.0000] <annevk>
I like the uncancellable idea

[10:38:46.0000] <annevk>
I'm surprised with the double l usage

[10:52:27.0000] <annevk>
/me bugs Kris https://twitter.com/annevk/status/568120153306734592

[10:57:12.0000] <jtcranmer>
annevk: fwiw, my motivation towards thinking about cancelling fetch was coming across this monstrosity of a pre-promise code:

[10:57:15.0000] <jtcranmer>
https://dxr.mozilla.org/comm-central/source/mailnews/base/prefs/content/accountcreation/fetchConfig.js

[10:58:31.0000] <annevk>
Kris replies! https://github.com/kriskowal/gtor/blob/master/cancelation.md

[10:58:37.0000] <annevk>
Also https://twitter.com/kriskowal/status/568120887112675328

[10:59:07.0000] <annevk>
jtcranmer: heh

[10:59:42.0000] <jtcranmer>
annevk: if an abortable promise concept were available, I would not have been able to resist the urge to refactor the entire bloody mess

[11:00:10.0000] <jtcranmer>
well, that and the Fetch API isn't quite implemented in Gecko yet

[11:00:51.0000] <annevk>
jtcranmer: see dev-platform, we might be shipping in Fx 38

[11:01:10.0000] <jtcranmer>
I did see that

[11:01:20.0000] <jtcranmer>
I was poking at it last night, though

[11:01:44.0000] <jtcranmer>
but I've got other code using XHR that I'm more minded to switch to Fetch now

[11:02:15.0000] <jtcranmer>
(assuming Fetch is exposed in JS modules)

[12:08:56.0000] <aklein>
Hixie: Structured Clone question, you about?

[12:10:08.0000] <annevk>
aklein: curious

[12:10:31.0000] <aklein>
annevk: the text of how to set values on objects says "Add a new property to output having the name name, and having the value cloned value."

[12:11:00.0000] <aklein>
(8.4 of https://html.spec.whatwg.org/multipage/infrastructure.html#internal-structured-cloning-algorithm)

[12:11:20.0000] <aklein>
I'm guessing that's intended to call [[DefineOwnProperty]] in ES

[12:11:25.0000] <aklein>
but it would be nice for it to be more explicit

[12:11:46.0000] <aklein>
(Chrome calls [[Set]], which can cause some surprising behavior)

[12:12:03.0000] <annevk>
aklein: https://github.com/dslomov-chromium/ecmascript-structured-clone

[12:12:30.0000] <annevk>
aklein: I recommend continuing to petition TC39 to embrace and extend it

[12:12:43.0000] <aklein>
annevk: yeah, I agree that that would help

[12:13:00.0000] <annevk>
aklein: that has [[Set]] but might be due to Chrome doing that, not sure what Firefox does

[12:13:12.0000] <aklein>
Firefox appears to create own properties

[12:13:26.0000] <aklein>
don't have anything else handy at the moment

[12:13:49.0000] <aklein>
HTML already refers to [[Get]]

[12:13:59.0000] <aklein>
so I don't see any reason why it couldn't use [[DefineOwnProperty]]

[12:14:14.0000] <aklein>
(or [[Set]], if that's actually intended)

[12:14:26.0000] <annevk>
aklein: I don't think there's any particular reason, no

[12:14:59.0000] <annevk>
aklein: might be worth filing a bug, though I would not expect priority to be particularly high

[12:15:15.0000] <annevk>
aklein: especially with that GitHub repository going on to take it out of HTML

[12:15:49.0000] <aklein>
I have a meeting tomorrow with dslomov, will ask him if he has background on the status

[12:16:23.0000] <aklein>
thanks for the pointer to that repo

[12:16:26.0000] <annevk>
aklein: let me know if he's no longer pushing it, might try to get HTML clarified instead then

[12:16:42.0000] <aklein>
I know it's not at the top of his priority queue

[12:23:43.0000] <aklein>
filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28052


2015-02-19
[20:29:59.0000] <Krinkle>
Hm.. is there an interface exposed in browsers to build a DOM from HTML gradually (as opposed to all at once). Essentially consuming a stream. While conceptually slow/complex to do manually (I think), the logic for deciding when a tag is save to include in the dom and how to build it already exists in browsers today. Exposing this with events would be interesting.

[20:34:21.0000] <MikeSmith>
Krinkle: what you're describing sounds pretty much like the SAX API

[20:34:56.0000] <MikeSmith>
which isn't something that browsers implement and it's kinda hard to imagine how they would usefully

[20:35:49.0000] <MikeSmith>
as far as the parsed document that browsers expose

[20:36:10.0000] <MikeSmith>
but I think there's at least one JS-based SAX implementation

[20:36:56.0000] <MikeSmith>
or you know about SAX already, maybe I'm not understanding what you're proposing

[20:37:08.0000] <MikeSmith>
*if you know about SAX already

[20:38:10.0000] <Krinkle>
The use case I'm working on is for Wikipedia's visual document editor. It loads an HTML5 representation of the article (essentially what readers see without a theme or scripts, and more data about where individual pieces originate from), uses DOMParser, and then processes that to compose a content editable surface.

[20:38:39.0000] <Krinkle>
It'd be rad to do that from a stream and start building our linear model while HTML is interpreted.

[20:39:25.0000] <Krinkle>
(e.g. XHR2 streams)

[21:01:19.0000] <MikeSmith>
rektide: ↑

[21:03:57.0000] <MikeSmith>
Krinkle: it sounds like a JS-based SAX parser could help get you there

[21:07:20.0000] <Krinkle>
MikeSmith: Yeah, there exist good SAX parsers for JSON. I'm skeptical how an HTML would work. Implementing html5 properly is no easy task. And I suspect it might perform poorly compared to native and perhaps nullify the advantage of streaming. Having said that, we have observed that parsing large documents can definitely take a considerable amount of time (seconds), so there's room.

[21:07:43.0000] <Krinkle>
MikeSmith: Though I forgot for a second that our internal html5 representation of the article content is actually valid XML as well.

[21:15:26.0000] <MikeSmith>
Krinkle: yeah if you need to make something that's capable of handling arbitrary HTML content from the Web, you need something that implements the HTML parsing algorithm, there's also the problem that there are parts of the HTML5 parsing algorithm that can't be implemented in truly streaming parser

[21:16:08.0000] <Krinkle>
MikeSmith: Yeah, but the spec handles quite explicitly from what I recall and browsers (nowadays) implement that.

[21:17:16.0000] <Krinkle>
Hence I figured it should be too complicated to expose since the behaviour is already specified. Since browsers generally do parse from a stream as well (e.g. server can flush buffer early).

[21:17:26.0000] <Krinkle>
shouldn't *

[21:18:43.0000] <Krinkle>
It'll probably never happen, but something like DOMParser that takes a Blob/Buffer (node-ism) and returns Promise with EventEmitter. That's what I'd expect server-side.

[00:45:46.0000] <annevk>
Domenic: did you see https://github.com/kriskowal/gtor/blob/master/README.md#singular-and-temporal from Kris?

[00:45:50.0000] <annevk>
Domenic: I guess you have

[00:46:37.0000] <annevk>
Domenic: it's kinda nice how he talks about futures/promises/tasks to mostly do the same thing, but I'm not sure I see JavaScript going that way

[00:46:43.0000] <annevk>
Domenic: but maybe at some point

[00:47:18.0000] <annevk>
Domenic: although on the other hand, people have trouble deciding between a promise and a callback; giving them three different types of promises might be a bit much

[00:58:59.0000] <nekllen>
Hi! I'd like to integrate with validator directly in my java code (rather than as an external http service); how possible is this?

[00:59:54.0000] <MikeSmith>
hi nekellen

[00:59:58.0000] <MikeSmith>
it's possible

[01:01:02.0000] <MikeSmith>
nekellen: the code you want to look as an example is https://github.com/validator/validator/blob/master/src/nu/validator/client/SimpleCommandLineValidator.java

[01:01:35.0000] <MikeSmith>
the entry point in the sources is https://github.com/validator/validator/blob/master/src/nu/validator/validation/SimpleDocumentValidator.java

[01:04:47.0000] <nekellen>
MikeSmith: ok, great. Is there some description of which dependencies I'll need to include? I saw in https://github.com/validator/validator/issues/13 that validator was potentially using older/unsupported versions of libs

[01:05:19.0000] <nekellen>
or are all of these getting included in validator.jar ?

[01:05:42.0000] <MikeSmith>
yeah the dependencies are all in validator.jar

[01:05:46.0000] <MikeSmith>
all 22MB of them

[01:09:32.0000] <MikeSmith>
in your code basically you want to do validator = new SimpleDocumentValidator() then validator.setUpMainSchema then validator.setUpValidatorAndParsers and then, depending on where the doc you're checking is coming from, either validator.checkHtmlInputSource or validator.checkHttpURL or validator.checkHtmlFile

[01:11:12.0000] <MikeSmith>
oh the other main thing you need to do first is to set up an ErrorHandler

[01:15:19.0000] <nekellen>
MikeSmith: That gives me a good place to start, thanks!

[01:15:56.0000] <MikeSmith>
cheers

[02:29:30.0000] <annevk>
wanderview: I just realized I have not adequately defined Headers' guard for cloning

[04:24:47.0000] <annevk>
Summary of fetch termination: https://annevankesteren.nl/2015/02/cancelable-promises

[04:30:11.0000] <zcorpan>
and darobin 386es Yucca

[04:30:40.0000] <darobin>
there are days on which it's impossible to resist :)

[04:31:03.0000] <zcorpan>
yeah i know

[04:31:14.0000] <annevk>
wanderview: btw, that guard thing is fixed now, while you sleep :p

[04:45:28.0000] <zcorpan>
where's krijn?

[04:57:53.0000] <zcorpan>
TabAtkins: i can add some headings to <img> i guess

[06:03:24.0000] <wanderview>
annevk: sleep is a strong word when you have a baby (which I'm sure you know)

[06:03:35.0000] <annevk>
heh

[06:04:53.0000] <zcorpan>
annevk: would it make sense to have a <meta> or <link> to invoke the OPTIONS * preflight, to reduce latency?

[06:05:36.0000] <zcorpan>
latency of the initial API use, i mean

[06:06:04.0000] <annevk>
zcorpan: requesting CORS for a particular origin? Yeah maybe

[06:06:15.0000] <zcorpan>
yeah

[06:08:44.0000] <zcorpan>
it would also provide an opt-in if it's not compatible to do OPTIONS * from APIs

[06:11:12.0000] <wanderview>
annevk: just to clarify... response2 = response1.clone()... response2 should have the same header guard as response 1, correct?

[06:12:19.0000] <wanderview>
/me reboots because windows decided to install updates.

[06:12:26.0000] <annevk>
wanderview: yup

[06:12:43.0000] <wanderview>
thanks

[06:43:05.0000] <tty>
hi all. i have made a top navigation menu that i want to include in two or more apps like wordpress. i want the apps to have the same global navigation. for the moment i have tried copy/paste the navigation html/css/js. i tried putting all js and css on one server and loading the navigation html with jquery enabling CORS. is there a better way to approach this? angularjs? iframes?

[07:04:39.0000] <jgraham>
annevk: Is it defined somewhere (url)? what the valid syntax of a path is?

[07:05:03.0000] <jgraham>
Oh yeah

[07:05:05.0000] <jgraham>
I see now

[08:05:21.0000] <annevk>
Domenic: bz thinks it's somewhat critical that eventually all consumers get some notification of cancelation

[08:05:32.0000] <annevk>
Domenic: is that a recognized goal of cancelable promises?

[08:08:37.0000] <annevk>
dglazkov: thanks for setting it all up!

[08:21:26.0000] <Domenic>
Krinkle|detached: MikeSmith: https://www.npmjs.com/package/parse5 has a streaming mode and at least in its normal mode passes all the parser tests. Don't know the details, but it might be interesting.

[08:22:02.0000] <Domenic>
annevk: yeah, I'm unsure on Task<T> being worth the trouble. Although, duck-typing would let most consumers treat them identically to promises.

[08:22:25.0000] <Domenic>
Future<T> seems much less interesting to me, but that's an age-old debate

[08:23:07.0000] <Domenic>
annevk: in practice we haven't found a use case for notifying consumers of cancellation

[08:23:17.0000] <Domenic>
everyone just filters out the cancellation rejection and ignores it.

[08:28:39.0000] <MikeSmith>
Domenic: niceーthanks

[08:29:07.0000] <annevk>
Domenic: okay, I should ask bz

[09:42:57.0000] <annevk>
Domenic: so bz brings up the case of the end user terminating fetches by hitting something in the UI

[09:43:10.0000] <annevk>
Domenic: is that cancel-like or network-error-like?

[09:43:20.0000] <Domenic>
annevk: that sounds network-error-like to me.

[09:43:22.0000] <annevk>
Domenic: what about killing a worker or navigating away from a page?

[09:43:31.0000] <annevk>
Domenic: okay, it currently is that way

[09:43:38.0000] <Domenic>
all of those cases sound the same as if the server just immediately cut off the connection

[09:44:13.0000] <annevk>
Domenic: but from the other consumers of the promise, how is one consumer cutting off the connection any different?

[09:44:58.0000] <Domenic>
annevk: yeah, multi-consumer is the problem indeed, hmm.

[09:45:45.0000] <annevk>
promise.onterminate trololol

[09:47:13.0000] <Domenic>
maybe .terminate({ rejectWith: }) provides the answer

[09:47:21.0000] <Domenic>
browsers do .terminate({ rejectWith: NetworkError })

[09:47:26.0000] <Domenic>
but most users do .terminate()

[09:49:27.0000] <TabAtkins>
I said that was a nice model. ^_^

[09:50:42.0000] <annevk>
Yeah, I guess the question is whether we should start with it or introduce it when it becomes a pain point

[09:53:57.0000] <Domenic>
yeah i was kind of hoping we would start with .terminate() and then find out we never needed { rejectWith }

[11:34:16.0000] <Krinkle>
Domenic: Thanks :)

[14:19:14.0000] <caitp->
are webidl attributes supposed to be configurable?

[14:19:25.0000] <caitp->
like, in general

[14:19:41.0000] <heycam>
yes, in general

[14:27:42.0000] <caitp->
hm, jsc does some weird stuff

[14:30:31.0000] <TabAtkins>
caitp-: Yes it does, but also note that WebKit/Blink put attributes in the wrong place.  They're placed on the object, when WebIDL says they should be getter/setters on the prototype.

[14:31:11.0000] <caitp->
i heard there was some progress on that, wasn't there?

[14:32:37.0000] <TabAtkins>
Yeah, we keep trying.

[14:48:09.0000] <gsnedders>
rewriting test harnesses has to be my least fun hobby ever

[14:50:49.0000] <espadrine>
I'm puzzled by window.location.hostname outputting IPv6 hostnames without the brackets.

[14:55:11.0000] <gsnedders>
espadrine: where's your sense of logic?

[14:55:36.0000] <espadrine>
let me put it at the door ☺

[15:39:56.0000] <MikeSmith>
about the fact that Blink and WebKit don't conform to the WebIDL requirement to expose DOM attributes as getters/setters of prototypes, what real-world differences in practice does that make for web developers?

[15:40:15.0000] <MikeSmith>
as far as how devs actually program to the APIs

[15:40:56.0000] <MikeSmith>
I guess it at least affects the case where somebody's monkey-patching the prototype?

[15:41:08.0000] <MikeSmith>
or not really?

[15:42:37.0000] <MikeSmith>
anyway it doesn't seem like that difference is a pain point for web devs to the point where any have taken time to complain about it

[15:44:10.0000] <MikeSmith>
so I wonder what real problems if any it's causing in practice

[15:50:14.0000] <Domenic>
MikeSmith: yes it affects monkey patching pretty drastically

[15:50:39.0000] <Domenic>
e.g. the shadow DOM polyfill has to monkey-patch all the constructors to produce instances with overwritten methods, instead of just monkey-patching the methods directly

[15:50:49.0000] <Domenic>
and even that doesn't catch instances that come from the browser itself

[15:51:08.0000] <Domenic>
so you have ot patch all methods that access e.g. Nodes and patch those nodes before the author sees them

[15:51:31.0000] <Domenic>
it's pretty disastrous

[15:51:49.0000] <Domenic>
(and slow)

[15:55:17.0000] <MikeSmith>
oh

[15:55:50.0000] <MikeSmith>
Domenic: thanks yeah I see now

[15:56:47.0000] <MikeSmith>
so I guess I'm now a bit surprised that more polyfill/library authors haven't complained about this more

[15:57:00.0000] <MikeSmith>
or maybe they have and I just wasn't paying attention

[15:57:27.0000] <smaug____>
now we need to convince only webkit to handle attributes properly

[15:57:38.0000] <MikeSmith>
anyway I guess the other elephant in the room on this is what plans does the WebKit team have if any for fixing this in WebKit

[15:57:51.0000] <MikeSmith>
smaug____: coke jinx

[15:59:41.0000] <MikeSmith>
smaug____: I wonder if there's even an open WebKit bug for it


2015-02-20
[16:00:09.0000] <smaug____>
I'm pretty sure I've seen such

[16:00:24.0000] <smaug____>
https://bugs.webkit.org/show_bug.cgi?id=49739

[16:01:57.0000] <TabAtkins>
We were trying to fix it pre-fork.  I assume people on that side are also at least somewhat interested in fixing it.

[16:02:18.0000] <TabAtkins>
Problem is that we micro-optimized ourself into a corner, so it's hard to fix without perf regressions on popular benchmarks.

[16:02:20.0000] <smaug____>
especially now if blink has the fix too

[16:03:33.0000] <smaug____>
I could be wrong, but I think bz got gecko's attribute handling performance to be between webkit and blink while those two were using the wrong attribute setup, and gecko had the one spec'ed

[16:04:17.0000] <smaug____>
(IIRC webkit is the fastest, at least in some microbenchmarks )

[16:24:30.0000] <MikeSmith>
TabAtkins: I hope the lesson has been learned about avoiding that "micro-optimized ourself into a corner" trap, so that another 5-year saga like this one doesn't end up happening again

[16:24:47.0000] <MikeSmith>
smaug____: thanks

[16:41:41.0000] <Domenic>
I am fuzzy on the details but I kind of remember recent WebKit releases doing halfway steps on this

[16:41:54.0000] <Domenic>
e.g. now they return getter/setters on introspection, but those getter/setters are very broken

[16:42:07.0000] <Domenic>
so if we interpret that optimistically then they are probably trying to move toward a fix

[16:51:16.0000] <MikeSmith>
Domenic: yeah there are some details along those lines in comments of the https://bugs.webkit.org/show_bug.cgi?id=49739 bug that smaug cited

[16:51:19.0000] <MikeSmith>
and at https://bugs.webkit.org/show_bug.cgi?id=141585

[16:51:37.0000] <MikeSmith>
https://bugs.webkit.org/show_bug.cgi?id=140575

[16:55:08.0000] <caitp->
[18:40]  <MikeSmith> I guess it at least affects the case where somebody's monkey-patching the prototype? << i brought up the webidl question because of a library being broken in webkit, assuming that little conversation followed from that

[16:55:25.0000] <MikeSmith>
caitp-: ah ok

[22:27:20.0000] <strugee>
Hixie: ping

[22:27:51.0000] <strugee>
we were going to talk about developers.whatwg.org?

[22:52:09.0000] <annevk>
espadrine: that's a bug

[22:54:39.0000] <annevk>
TabAtkins: status of converting DOM?

[00:02:45.0000] <annevk>
Domenic: I think the strategy of forever pending and maybe adding rejecting later is okay, though bz brings up a valid point

[00:03:12.0000] <annevk>
Domenic: "[I]s this sufficient to actually build a browser on top of fetch? How is the browser expected to implement things like the stop button or the request-killing on navigation, if not by effectively calling terminate() on all the fetches involved?"

[02:00:02.0000] <annevk>
hsivonen: your last tweet fails at grammar

[02:36:44.0000] <Seplonger>
...

[03:03:06.0000] <annevk>
I should maybe write a post about CORS since the amount of people not grokking the same-origin policy is disturbing

[03:10:19.0000] <JakeA>
annevk: are you around this evening for a call about SW clients & postmessage? Monday otherwise?

[03:27:52.0000] <strugee>
 /quit

[04:22:49.0000] <annevk>
JakeA: yeah, can do, though I don't really have any new thoughts

[04:54:29.0000] <Ms2ger>
SimonSapin, TabAtkins sold his house in Texas, IIRC

[04:54:42.0000] <SimonSapin>
oh, I see

[05:15:56.0000] <hsivonen>
annevk: yeah. it's annoying when a tweet becomes nonsensical due to proof reading failure after editing for 140 characters

[05:16:12.0000] <hsivonen>
annevk: also annoying to notice it after it has a reply

[05:46:57.0000] <hemanth>
/me : Superfluous Patterns of Javascript -> http://h3manth.com/new/blog/2015/superfluous-patterns-of-javascript/

[07:14:56.0000] <TabAtkins>
Ms2ger: ??? What's the relevance of my house?

[07:15:30.0000] <TabAtkins>
Never mind, I see.

[07:25:30.0000] <JonathanNeal>
http://dev.w3.org/csswg/css-font-loading/ Is there a friendly guide out there to using this? I have a knack for hanging the entire browser when I pass a second parameter into new FontFace

[07:28:12.0000] <JonathanNeal>
A third parameter, rather. e.g. new FontFace(family, source, descriptor); where name is “Balto”, source is ‘local(“Balto”)’ and descriptor is { weight: ‘bold’ }. Totally hangs the page. Is it the browser, or am I not following the spec?

[08:41:15.0000] <terinjokes>
JakeA: just checking in to make sure you locked yourself in a room and wrote your talk

[08:52:26.0000] <JakeA>
terinjokes: I'm still massively behind, so I'll be working the weekend :/

[08:55:55.0000] <terinjokes>
JakeA: bummer, but no worries

[08:56:37.0000] <Domenic>
annevk: OK, that makes me want to add rejectWith out of the gate

[09:02:49.0000] <JakeA>
Domenic: I did some mental flailing around fetchPromise https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75217729 - am I anywhere near?

[09:11:50.0000] <annevk>
Domenic: hah

[09:32:08.0000] <caitp->
what ever happened to the network infor api?

[09:32:19.0000] <caitp->
fell off the face of the earth?

[09:32:50.0000] <tantek>
overdesigned to the point of bloat death?

[09:33:52.0000] <caitp->
looks pretty small as these things go, actually

[09:36:08.0000] <annevk>
The use cases were not compelling I believe

[09:36:11.0000] <annevk>
Been a while

[09:37:36.0000] <Hixie>
strugee: here onw

[09:37:37.0000] <Hixie>
now

[09:40:26.0000] <caitp->
annevk it looks like it's implemented perfectly happy on mobile devices, are you saying service worker was probably a better approach?

[09:40:56.0000] <tantek>
annevk - the simple common use-case is, don't burn my mobile data with background network updates and crap.

[09:41:14.0000] <tantek>
ergo, the simple v0 API should be a boolean - navigator.NetworkInfo.IsMetered()

[09:41:58.0000] <Hixie>
annevk: btw did you see the web intents post-mortem post?

[09:41:59.0000] <tantek>
but noooooooo, people had to go and add all kinds of lower level plumbing details that frankly no real world web app builder actually cares about.

[09:43:12.0000] <tantek>
note that latest Android OS has this exact boolean feature for app devs, INCLUDING, a UI for users to toggle whether any particular wifi SSID is metered or not.

[09:43:49.0000] <tantek>
that really is all you need to cover the common use-case noted above. and that's all that a v0 network info api should include, ship, get interop on.

[09:44:03.0000] <tantek>
shove all the rest of the net info details to the next version

[09:44:11.0000] <caitp->
that does seem pretty reasonable

[09:44:12.0000] <annevk>
Hixie: from Paul? I did

[09:44:17.0000] <Hixie>
annevk: cool

[09:44:26.0000] <tantek>
catip - it's too reasonable to actually succeed in a discussion beyond 2-3 people.

[09:44:31.0000] <annevk>
Hixie: having said that, I still haven't really cracked a flow that works well

[09:44:43.0000] <tantek>
then everyone starts yanking out their pet armchair dev requirements / wishlists etc.

[09:44:48.0000] <annevk>
Hixie: one of the big problems is also convincing service providers that they want decentralization

[09:44:55.0000] <Hixie>
annevk: heh yeah

[09:45:17.0000] <annevk>
Hixie: e.g. I Facebook and Twitter and such seem quite content with all the promotion across millions of properties

[09:45:23.0000] <caitp->
well, you probably don't need to care exactly how your connection works, but you probably want to have some idea of whether it's a weak or strong connection

[09:45:25.0000] <annevk>
s/I//

[09:46:11.0000] <caitp->
i can see people wanting that :>

[09:47:26.0000] <tantek>
catip - "can see people wanting" is a horrible way to design anything

[09:47:27.0000] <annevk>
Hixie: perhaps the way out is continuing to provide easy ways for sites to collaborate and share data client-side and hope patterns emerge

[09:47:46.0000] <Hixie>
annevk: yeah, i dunno. just thought it was an interesting and candid post-mortem.

[09:47:53.0000] <Hixie>
annevk: with good lessons.

[09:48:04.0000] <annevk>
Hixie: e.g. cross-origin workers, the service worker to service worker messaging

[09:48:25.0000] <annevk>
Hixie: yeah, that was real cool of him

[09:55:53.0000] <Domenic>
JakeA: on my to-do list for today :)

[10:01:25.0000] <JakeA>
Domenic: no rush, I'm sure it's full of fundamental misunderstandings

[10:04:30.0000] <jgraham>
Anyone know anything about the Chromium CI setup?

[10:04:50.0000] <jgraham>
Specifically which servers / ports are avaliable / default

[10:28:52.0000] <TabAtkins>
tantek: Some apps on my phone act differently on wifi vs cell, even when both are unmetered.

[10:29:24.0000] <tantek>
TabAtkins - interesting. which apps, and do you know how they tell? (i.e. do they measure the bandwidth, do they query a proprietary API?)

[10:29:33.0000] <annevk>
TabAtkins: DOM ping?

[10:29:34.0000] <tantek>
and what different behavior(s)?

[10:29:34.0000] <TabAtkins>
JonathanNeal: If you're getting browser hangs for any reason, it's a bug.  In your partiucular case, it's *definitely* a bug.

[10:30:00.0000] <TabAtkins>
tantek: G+ gives me the option to only photo-sync while on wifi.

[10:30:21.0000] <TabAtkins>
annevk: Gonna try to finish today. :/ If you have any edits you need to make, though, feel free; I'll take the merge pain myself.

[10:30:55.0000] <annevk>
TabAtkins: nah, I'll be patient

[10:30:59.0000] <tantek>
TabAtkins: I hope that means non-metered wifi, otherwise it's still a problem

[10:31:07.0000] <annevk>
TabAtkins: though with continued nagging :p

[10:31:17.0000] <TabAtkins>
I mean, I guess it matters what you mean by "metered". I don't pay per Mb or anything, but I do have a 2.5Gb/month limit.

[10:31:23.0000] <TabAtkins>
annevk: That works too. ^_^

[10:31:29.0000] <TabAtkins>
tantek: And yes, wifi is non-metered.

[10:33:32.0000] <caitp->
well, it depends

[10:33:58.0000] <caitp->
sometimes paid wifi gives you N megabytes, sometimes N minutes

[10:34:22.0000] <caitp->
you wouldn't want to waste bandwidth on stuff you don't need

[10:37:30.0000] <annevk>
JakeA: Domenic: thanks for laying the groundwork on all the subclassing questions

[10:38:05.0000] <tantek>
TabAtkins: cool. Do you have that preference panel where you can toggle a switch next to each SSID as to whether it is metered or not?

[10:38:05.0000] <JakeA>
annevk: I'm all about the questions. Answers… not so much

[10:38:09.0000] <tantek>
I think it's in the latest Android OS update

[10:38:14.0000] <tantek>
(pretty new)

[10:38:28.0000] <TabAtkins>
annevk: So I was thinking about terminate() again, and I think GTOR is right - a cancelable thing is a Task, not a Promise. Luckily, a Task is a Promise subclass (I think it's literally a Liskov subclass, but even if not, it ducktypes as such).

[10:38:32.0000] <tantek>
caipt - correct on both accounts

[10:38:34.0000] <annevk>
JakeA: FWIW, with regards to AbortablePromise, the idea was to have FetchPromise and terminate() as method, and then introduce the more generic variant as a class inbetween later

[10:38:38.0000] <tantek>
caitp

[10:38:47.0000] <JakeA>
wfm

[10:39:06.0000] <TabAtkins>
All this really means is that chaining off of a Task returns Promises; you need a separate explicitly cloning method to return a Task with the same special abilities as the original one.

[10:39:29.0000] <TabAtkins>
So yeah, FetchPromise.then() returns a Promise, nice and easy.

[10:39:44.0000] <annevk>
TabAtkins: interesting idea

[10:39:55.0000] <annevk>
TabAtkins: I'm not sure that's how promise subclasses work though

[10:40:02.0000] <JakeA>
It isn't

[10:40:06.0000] <JakeA>
at the moment

[10:40:09.0000] <annevk>
TabAtkins: don't they do new this.constructor for .then()?

[10:40:09.0000] <TabAtkins>
tantek: No, I have no such toggle.

[10:40:50.0000] <JakeA>
They get their constructor from @@species, so I guess FetchPromise could set its @@species to Promise

[10:41:02.0000] <TabAtkins>
For predictability, though, you should have a way to convert Tasks into Promises; a Task is a Promise you can fuck with, and that's not an ability you want to give out normally.

[10:41:06.0000] <tantek>
Hmmm… ok then maybe I was looking at something beta. Um ok I won't say on who's device then. TabAtkins perhaps ask a co-worker to see their list of SSIDs preference screen on their Android ;)

[10:41:18.0000] <JakeA>
But I like the idea of fetch(url).then(r => r.json()) being abortable

[10:41:19.0000] <TabAtkins>
Not all Promise subclasses are Tasks; most can reconstruct an instance of the same class no problem.

[10:41:48.0000] <annevk>
JakeA: I guess you'd have to do fetch(url).specialThen(...) instead

[10:41:57.0000] <annevk>
JakeA: if we adopt this Task idea

[10:42:05.0000] <TabAtkins>
If we wanna be decent about the theoretics of this, yeah.

[10:42:22.0000] <TabAtkins>
Rather than munging everything up and having trouble later when we want to do something more principled.

[10:42:32.0000] <TabAtkins>
(It's the difference between piping and broadcasting in Stream.)

[10:42:52.0000] <annevk>
otoh, tasks could also have a cloning .then(), and a .promise() for discarding responsibility...

[10:43:12.0000] <TabAtkins>
Yeah, that's another way. Depends on how you want the "default" behavior to work.

[10:43:16.0000] <TabAtkins>
Either way is defensible.

[10:45:17.0000] <JakeA>
So are we losing the ability for `var p = fetch(url1).then(_ => fetch(url2));` then later `p.abort()` to abort whichever request(s) are in flight?

[10:45:30.0000] <JakeA>
(not I'm particularly against that, just trying to understand)

[10:45:41.0000] <TabAtkins>
JakeA: You wouldn't be losing it regardless; question is just how you want the default semantics to work.

[10:46:05.0000] <TabAtkins>
Oh wait, though; I didn't know that the p1=>p2 aborting was a thing to preserve.

[10:46:17.0000] <TabAtkins>
Though monadically that seems okay.

[10:47:11.0000] <JakeA>
TabAtkins: This is just my mental flailing. Posted a finger-in-the-air set of expectations at https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75217729

[10:48:03.0000] <annevk>
JakeA: for case 3 the expectation is that the promise is instead forever pending

[10:48:06.0000] <TabAtkins>
Let's assume that .then still returns a Task, and .promise() returns a Promise of it (losing the special abilities to fuck with the result).  Then when .then() is combining a second FetchTask into the first, it can combine permissions, so that aborting one aborts all.

[10:48:14.0000] <annevk>
JakeA: not rejected due to canceling

[10:49:05.0000] <JakeA>
annevk: so cancelling doesn't reject?

[10:49:26.0000] <annevk>
JakeA: yeah, the desired default seems to be to not reject

[10:49:46.0000] <annevk>
JakeA: if you want to reject, use p.terminate({rejectWith: "heya"})

[10:49:56.0000] <TabAtkins>
Case 3 seems slightly non-intuitive, and difficult to do.  It requires tasks to control down-stream tasks too; we're now talking more of a stream than a promise.

[10:50:32.0000] <JakeA>
annevk: so an "await p" would just hang forever. That isn't what I'd expect but I haven't really thought it through

[10:51:08.0000] <annevk>
JakeA: https://annevankesteren.nl/2015/02/cancelable-promises has a summary and pointers

[10:51:13.0000] <JakeA>
TabAtkins: is you want to cast a promise subclass to a normal promise, Promise.resolve(subclassPromise) is the current way

[10:51:17.0000] <TabAtkins>
JakeA: Well, until the method got aborted.

[10:51:24.0000] <TabAtkins>
JakeA: All right.

[10:56:50.0000] <JakeA>
annevk: yeah, ok, I think that makes sense. I've actually got some hacky code in SVGOMG because of promises that reject following aborting https://github.com/jakearchibald/svgomg/blob/9d23d77e389d62beb7acd16413a13328e568bdfd/src/js/page/main-controller.js#L217

[11:01:40.0000] <annevk>
JakeA: hah, that's exactly Domenic's prediction

[11:01:55.0000] <annevk>
JakeA: people writing if(e instanceof CancelableError) return

[11:03:11.0000] <Domenic>
@@species returns this so it automatically will return FetchPromise

[11:03:30.0000] <JakeA>
annevk: However, I do want to stop a spinner on cancellation, which pending forever won't support

[11:03:47.0000] <Domenic>
To convert tasks to promises do Promise.resolve(task)

[11:04:58.0000] <JakeA>
Problem with @@species is you lose the link to the original fetch, since @@species is got from this.constructor rather than this

[11:05:05.0000] <annevk>
JakeA: in that case use rejectWith I guess

[11:05:53.0000] <TabAtkins>
You gotta define a special .then() to get the right behavior, I think.

[11:06:07.0000] <JakeA>
annevk: yeah, so I'd be back to my if-instanceOf. Hmm

[11:06:12.0000] <TabAtkins>
So you can set the right internal slots, etc.

[11:07:09.0000] <JakeA>
TabAtkins: I came to that conclusion in https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75217729 - but feels cleaner if @@species was got from `this`

[11:07:31.0000] <JakeA>
(and Promise would define it on the prototype chain)

[11:07:55.0000] <TabAtkins>
But you lose the ability to cancel the fetch, or to combine fetches into a single cancelable thing.

[11:08:50.0000] <TabAtkins>
Ugh, if you want fetches to stack like that, we really do need to be more strict about it being a Task, and .then() being the Promise-returning method.

[11:09:03.0000] <JakeA>
Do you? Couldn't this.@@species carry over the state from this

[11:09:17.0000] <TabAtkins>
Because it's not cool if you chain two separate fetches off of a parent fetch, abort one of the children, and that causes the parent to abort.

[11:09:17.0000] <JakeA>
I guess it couldn't if it was called as a constructor

[11:09:39.0000] <JakeA>
hm, that's a good point

[11:09:59.0000] <JakeA>
Going to add that to the github issue

[11:10:01.0000] <TabAtkins>
You need to explicitly clone the parent fetch, so it can refcount itself and only abort itself if all the chained fetches abort.

[11:10:28.0000] <TabAtkins>
Again, this is stream-as-pipe vs stream-as-broadcast. If you want piping-like functionality, gotta be proper about it.

[11:11:34.0000] <TabAtkins>
If you try to mix it with the broadcast functionality, you're gonna have confused-deputy/ambient-authority bugs all over the place.

[11:12:28.0000] <JakeA>
https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75300556

[11:25:22.0000] <Domenic>
if (instanceof) seems fine if you're going to do something besides just return and try to ignore it

[11:31:24.0000] <Domenic>
TabAtkins: lol "I'd link you, but I think I accidentally killed the spec;"

[12:30:28.0000] <TabAtkins>
annevk: I'm suddenly confused.  DOM appears to have a dom-core.bs file now?

[12:30:44.0000] <TabAtkins>
The version I cloned originally only had Overview.src.html and dom-core.html

[12:37:19.0000] <TabAtkins>
annevk: I ask because I've been converting Overview.src.html into Overview.bs.

[12:38:19.0000] <TabAtkins>
Ah, looks like dom-core.bs is just a very light transliteration; not a ton of work went into it.  Good.

[14:56:37.0000] <JonathanNeal>
Is there a native JS method to enumerate the device fonts? Simulation: http://sandbox.thewikies.com/document.fonts.enumerate/

[15:15:08.0000] <Ms2ger>
JonathanNeal, that's a huge fingerprinting vector

[15:18:45.0000] <TabAtkins>
It's also already completely possible with high fidelity, so...

[15:19:29.0000] <TabAtkins>
It does indeed give you a bunch of identity bits, but you can't avoid it, since local font selection affects layout.

[15:19:55.0000] <TabAtkins>
JonathanNeal: I do plan to do *something* about querying local fonts in Font Loading. Just not sure what yet.

[15:47:05.0000] <zewt>
man, does anyone know if there's a switch somewhere to unbreak user scripts in chrome

[15:54:39.0000] <TabAtkins>
They getting CSP'd?

[15:57:43.0000] <JonathanNeal>
TabAtkins: what did you and Ms2ger mean by huge fingerprinting vector?

[15:58:15.0000] <TabAtkins>
That it expose a huge source of identity bits.  The precise set of fonts you have on your system is pretty unique.

[15:59:43.0000] <JonathanNeal>
Right!


2015-02-21
[16:01:16.0000] <caitp->
is it that unique?

[16:01:38.0000] <TabAtkins>
Yes.

[16:01:59.0000] <caitp->
i'd bet most people don't intentionally seek out and add new fonts to their system

[16:02:02.0000] <TabAtkins>
It at least gives several bits to the fingerprint.

[16:02:14.0000] <TabAtkins>
They don't have to; the programs they install often do.

[16:02:20.0000] <caitp->
sure, but there's already tons of those "fingerprinty" bits already exposed

[16:02:36.0000] <JonathanNeal>
Silverlight has InstalledFontCollection. AS3 has enumerateFonts.

[16:02:39.0000] <TabAtkins>
The precise version of Word you have affects which fonts you have installed.

[16:02:40.0000] <caitp->
i'm not saying it would be good to make it worse :p

[16:03:09.0000] <TabAtkins>
I agree - I think fingerprinting is already so easy that it's not worth fighting against it.

[16:05:41.0000] <JonathanNeal>
For an unknown reason to me, Chrome returns a list of font families while every other browser returns a list of font families combined with their weight, as though it were compiled by filename.

[16:06:40.0000] <zewt>
unless you're behind a proxy fingerprinting is basically already irrelevant (IPs), so it seems like anti-fingerprinting stuff can mostly be behind a switch for those people

[16:07:00.0000] <zewt>
(not that I'd go too far--wouldn't want to expose a client UUID)

[16:07:38.0000] <JonathanNeal>
zewt: in private browsing, a browser could prevent JavaScript from fetching the installed font list.

[16:08:01.0000] <zewt>
like i said, a switch

[16:08:35.0000] <TabAtkins>
zewt: I mean, adding more fingerprinty stuff and saying "have a switch to disable it" just means a lot of pages will break.

[16:08:51.0000] <TabAtkins>
A switch that makes the APIs lie is better, but more work.

[16:08:53.0000] <zewt>
TabAtkins: "disable it" means "make them act like a common user"

[16:08:54.0000] <JonathanNeal>
zewt: and that’s already the case in the example I posted above.

[16:09:01.0000] <zewt>
eg. only list a few base fonts instead of all fonts

[16:09:18.0000] <TabAtkins>
So if we give up on stopping fingerprinting, we're still creating more work for those people who are concerned about it.

[16:15:23.0000] <JonathanNeal>
TabAtkins: where were you thinking of putting such a feature and how might you have expected it to work? Is there a draft anywhere?

[16:15:52.0000] <TabAtkins>
JonathanNeal: No draft. I would probably just let you enumerate all the fonts. Problem is what to expose on the object; local fonts don't have a single concept of "name".

[16:16:32.0000] <zewt>
can probably profile a lot from fonts anyway just by doing layout and checking the results to see if it's installed, so browsers that care about privacy would need to be able to limit available fonts anyway

[16:17:07.0000] <TabAtkins>
zewt: Yes, that's what I said earlier.  If you just have a few thousand font names and a few seconds of compute time, you can probe someone's installed local fonts today.

[16:17:27.0000] <TabAtkins>
And you can't stop it.  It's impossible, because "stopping" it would involve making font choice somehow not affect layout.

[16:18:49.0000] <TabAtkins>
Enumerating local fonts does *technically* increase the fingerprinting surface a little bit, as it exposes all fonts, not just those on your predefined list, but it's tiny relative to the existing fingerprint leak.

[16:19:01.0000] <zewt>
could stop it by limiting fonts, but only people who actually need that level of anonymity would want that (and that's not what "private browsing modes" are for)

[16:19:47.0000] <zewt>
TabAtkins: changes it in a different way (lots of people would be roughly the same, but a small number of people would be far more fingerprintable, which is what happens with a lot of fingerprinting)

[16:19:48.0000] <JonathanNeal>
TabAtkins: Looking, they do have a name field, and a name + style field.

[16:21:11.0000] <TabAtkins>
JonathanNeal: They have *several* name fields, and different OSes use different combinations of them.

[16:21:13.0000] <zewt>
(actually, doing that sort of thing in private browsing mode would probably be bad, since it gives a confusing message to naive users about what "private browsing" actually gives you)

[16:21:37.0000] <JonathanNeal>
TabAtkins: Right, I was just looking at otf.

[16:22:41.0000] <JonathanNeal>
Whatever Chrome/Flash is doing in my example seems right. The other browsers seem more primative.

[16:25:16.0000] <JonathanNeal>
So, at some level, I wonder if Chrome is already thinking about this.

[16:26:01.0000] <JonathanNeal>
Maybe not for such a feature, but for some reason, they group fonts by name only when they can.

[16:30:25.0000] <TabAtkins>
That is also a hard thing; some (legacy?) programs only allowed a small number of fonts per family, so large families had to be broken up, and some software manually re-stitches them back into a single virtual family.

[16:33:46.0000] <TabAtkins>
annevk: Please convince Domenic that he's wrong. ^_^

[16:37:39.0000] <TabAtkins>
Domenic: You agreed with the pipe/broadcast distinction for Streams. Why do you disagree with it here?

[22:58:53.0000] <annevk>
TabAtkins: https://github.com/whatwg/dom/ does not show dom-core.bs

[00:48:01.0000] <strugee>
]

[00:49:01.0000] <strugee>
sorry, didn't mean to say anything

[00:49:13.0000] <strugee>
/me rolls eyes at self

[12:36:21.0000] <TabAtkins>
annevk: Hmmmmm, my fork doesn't show dom-core.bs either.  But where did it come from, then? I'm so confused.

[12:36:29.0000] <TabAtkins>
I guess I did it myself and then forgot about it?

[13:03:24.0000] <TabAtkins>
But for serious annevk, how did your fingers not fall off typing all these excessively long autolinks?


2015-02-22
[16:17:44.0000] <TabAtkins>
Phew, nearly done with DOM.

[16:18:04.0000] <TabAtkins>
Only at line 4500, but it moves extremely fast now that most links have been converted.

[16:18:20.0000] <TabAtkins>
Then there's the slogging task of fixing all the linking failures, which hopefully shouldn't be too long.

[17:43:18.0000] <strugee>
Hixie: ping

[17:43:38.0000] <Hixie>
yo

[17:43:56.0000] <strugee>
we were going to discuss developers.whatwg.org

[17:44:04.0000] <Hixie>
yesyes

[17:44:18.0000] <strugee>
ok

[17:44:19.0000] <strugee>
so

[17:44:54.0000] <strugee>
/me looks at the GitHub issue

[17:47:04.0000] <strugee>
hmm

[17:47:11.0000] <strugee>
so how complex is your script?

[17:47:40.0000] <strugee>
do you actually have to parse the entire document into a DOM-like structure, or can you parse individual parts?

[17:49:38.0000] <Hixie>
i parse the entire thing into a dom

[17:49:46.0000] <Hixie>
then do extensive manipulations on it

[17:49:50.0000] <Hixie>
then serialise it back out

[17:50:18.0000] <strugee>
right

[17:50:28.0000] <strugee>
but do you actually need to?

[17:50:48.0000] <Hixie>
what would constitute a need to?

[17:50:52.0000] <Hixie>
i mean, i dunno how to answer that question

[17:51:07.0000] <Hixie>
the code to do it is http://software.hixie.ch/applications/wattsi/src/wattsi.pas

[17:51:34.0000] <strugee>
e.g. to change the <title> you could find the beginning and end of <head> and parse that, then change <title>

[17:51:44.0000] <strugee>
so you wouldn't have to parse the entire document

[17:51:55.0000] <strugee>
ok, thanks for the link

[17:51:56.0000] <Hixie>
how do you "find the beginning and end of <head>" without parsing it?

[17:52:12.0000] <Hixie>
(the code above isn't quite complete, there's also some glue perl code that isn't published anywhere)

[17:52:26.0000] <Hixie>
(but the heavy lifting is in that file)

[17:53:20.0000] <strugee>
you just search for the keyword "<head>" in the string

[17:53:42.0000] <strugee>
obviously that doesn't work on arbitrary documents but since the source is in a known state I think we can get away with it

[17:53:54.0000] <strugee>
unless I'm doing something dumb?

[17:54:52.0000] <Hixie>
i mean, i don't guarantee that i won't change that to <head class="draft"> or something

[17:55:15.0000] <Hixie>
in particular, i don't see how that would work for the headings and cross-references

[17:55:18.0000] <Hixie>
which are all over the place

[17:55:23.0000] <strugee>
so use the keyword "<head" instead of "<head>"

[17:55:28.0000] <strugee>
ok, that was what I was asking

[17:55:41.0000] <Hixie>
i don't guarantee i won't spell it "<HEAD" or remove the tag and rely on it being implied

[17:55:47.0000] <strugee>
right

[17:55:52.0000] <Hixie>
who knows what i'll be doing 10 years from now :-)

[17:56:16.0000] <strugee>
/me chuckles

[17:56:30.0000] <strugee>
ok, scratch that idea :)

[17:56:43.0000] <strugee>
are you familiar with Node.js streams?

[17:56:49.0000] <strugee>
that was what I was trying to make it fit into

[17:57:20.0000] <Hixie>
i'm not very familiar with Node.js

[17:57:27.0000] <Hixie>
only done one project in it and it was a while ago

[17:57:30.0000] <strugee>
ok

[17:58:09.0000] <strugee>
the basic idea is that you do transforms on a stream of text instead of a string

[17:58:41.0000] <Hixie>
i mean i'm familiar with the idea of streams in general

[17:58:44.0000] <Hixie>
they're not new :-)

[17:59:05.0000] <strugee>
right :)

[17:59:09.0000] <Hixie>
i don't think you can use a one-pass approach with this though, since the cross-references go both ways

[17:59:22.0000] <strugee>
ok

[17:59:32.0000] <strugee>
makes sense

[17:59:52.0000] <Hixie>
i mean, at the most basic level, if you want to output the table of contents at the start, you need to have seen the last heading before you output the table of contents

[18:00:08.0000] <strugee>
yeah

[18:01:01.0000] <strugee>
I wonder if you could collect all the footnotes, headers, etc. in one pass and then write them in in a second

[18:01:26.0000] <strugee>
if worst comes to worse I can just buffer the document and parse

[18:01:50.0000] <Hixie>
well, html parsing as a general case is a non-streaming operation

[18:02:21.0000] <Hixie>
but you can probably assume that i don't rely on things like bogus table parsing and so skip those parts

[18:02:24.0000] <Hixie>
i guess

[18:02:58.0000] <Hixie>
writing an html parser using the spec's built-in model is a pretty large task as it is

[18:03:11.0000] <Hixie>
writing one in another model entirely is a whole extra level of pain

[18:03:29.0000] <Hixie>
since you have to be able to reason about all the implications

[18:05:54.0000] <strugee>
yeah, no kidding

[18:08:07.0000] <strugee>
hmm

[18:09:17.0000] <Hixie>
that's why i was saying you really want an off-the-shelf parser if you're not relying on the output of mine

[18:10:16.0000] <Hixie>
(though it has to be a pretty configurable one since i add a new void element)

[18:10:23.0000] <Hixie>
(and a bunch of attributes)

[18:11:34.0000] <Hixie>
the alternative is you tell me what the output should be and i just generate it

[18:11:54.0000] <strugee>
ok

[18:12:28.0000] <Hixie>
i mean, i already generate https://html.spec.whatwg.org/.wattsi-output/multipage-dev/

[18:12:32.0000] <Hixie>
which is pretty close, i'd wager

[18:12:46.0000] <Hixie>
that output would be very regular html

[18:12:53.0000] <Hixie>
which you could then massage more easily

[18:13:01.0000] <Hixie>
if you wanted to

[18:15:30.0000] <strugee>
ok

[18:15:39.0000] <strugee>
yeah, that would be nice

[18:16:39.0000] <strugee>
what's done to that version?

[18:16:43.0000] <strugee>
transform to HTML and strip non-dev content?

[18:17:02.0000] <strugee>
if so then I think we'd just need to insert styles and fix the title

[18:17:16.0000] <strugee>
or not even the title, since I think that's done already in the source

[18:18:08.0000] <Hixie>
what should the style link be?

[18:20:46.0000] <Hixie>
i've added a <link> to styles.css in the same directory

[18:20:55.0000] <Hixie>
want some <script src=""> too?

[18:21:00.0000] <Hixie>
and anything else?

[18:21:17.0000] <Hixie>
the old developers.w.o version had some different handling of references

[18:21:21.0000] <Hixie>
i'm happy to do something with that too

[18:22:18.0000] <strugee>
yeah, I think we'll need scripts

[18:22:28.0000] <strugee>
I can take care of minifying it into one file

[18:22:57.0000] <strugee>
so just a scripts.js in the root would be fine, I think

[18:27:15.0000] <strugee>
I'm getting 404 on https://html.spec.whatwg.org/.wattsi-output/multipage-dev/

[18:28:18.0000] <strugee>
and https://html.spec.whatwg.org/.wattsi-output/ shows a directory listing with nothing in it

[18:29:24.0000] <Hixie>
yeah the caniuse.json data is broken

[18:29:34.0000] <Hixie>
which is breaking my script

[18:31:53.0000] <strugee>
ok

[18:32:09.0000] <strugee>
so when that's fixed, stuff will magically appear in that directory?

[18:32:12.0000] <Hixie>
yeah

[18:32:15.0000] <Hixie>
well

[18:32:20.0000] <Hixie>
not when caniuse.json is fixed

[18:32:23.0000] <Hixie>
but when i work around it

[18:32:25.0000] <Hixie>
in a few minutes

[18:32:30.0000] <Hixie>
i tried deleting the file

[18:32:34.0000] <Hixie>
and my script was unhappy

[18:33:13.0000] <Hixie>
man my script really freaking wants real data in this file

[18:33:52.0000] <Hixie>
hm this file isn't broken, wtf

[18:34:02.0000] <Hixie>
maybe there's a bug in my json parser

[18:35:01.0000] <Hixie>
something fishy going on

[18:35:21.0000] <strugee>
ok

[18:35:25.0000] <strugee>
keep me posted

[18:37:03.0000] <Hixie>
wt_f_

[18:37:06.0000] <Hixie>
wget is screwing me

[18:38:23.0000] <Hixie>
$ wget -o /dev/null -O caniuse.json  --no-check-certificate https://raw.githubusercontent.com/Fyrd/caniuse/master/data.json

[18:38:26.0000] <Hixie>
$ wget -o /dev/null -O caniuse2.json --no-check-certificate https://raw.githubusercontent.com/Fyrd/caniuse/master/data.json

[18:38:29.0000] <Hixie>
$ sha512sum caniuse*

[18:38:32.0000] <Hixie>
10acc62e0124195a1378b1ea79a91db4f13d861629afdcf76a928c2e7b359a890cdc0d5ee261d138aa4a86544b8b648a4cd44cdb610a7391fdddda861594b688  caniuse2.json

[18:38:35.0000] <Hixie>
805859fcdf2d05c06e3f35a0bc7f539d7dbe02d613c06dc4475592bd5e9204161a659573edfff96ae0121c00bbcd3fa89d1802fbd07507714e180c4ffbd673cc  caniuse.json

[18:42:28.0000] <strugee>
it couldn't be changing that fast, could it?

[18:42:35.0000] <Hixie>
no

[18:42:37.0000] <Hixie>
no idea what's up

[18:42:55.0000] <strugee>
let me try

[18:44:26.0000] <Hixie>
it worked once i nuked the existing file on disk a second time

[18:44:29.0000] <Hixie>
dunno what's up with THAT

[18:44:43.0000] <Hixie>
wget trying to do some sort of completion or something

[18:44:43.0000] <strugee>
_weird_

[18:44:49.0000] <strugee>
mine match, by the way

[18:44:54.0000] <strugee>
I did it with curl

[18:44:57.0000] <Hixie>
mine too, now. :-/

[18:45:01.0000] <Hixie>
anyway, look now

[18:45:07.0000] <strugee>
ok

[18:47:00.0000] <strugee>
ok, fantastic

[18:47:45.0000] <strugee>
by the way, what's link-fixup.js?

[18:48:05.0000] <strugee>
it's 404ing in my console when I load multipage-dev/

[18:48:16.0000] <Hixie>
handles breaking links

[18:48:28.0000] <Hixie>
try html.spec.whatwg.org/multipage/#the-canvas-element

[18:49:08.0000] <strugee>
s/multipage/multipage-dev/?

[18:51:26.0000] <Hixie>
in theory it works for the multipage-dev version too

[18:51:33.0000] <strugee>
nevermind

[18:51:36.0000] <Hixie>
but i was giving you an example of it working on the spec multipage version

[18:51:57.0000] <strugee>
no, I see what you were saying now

[18:52:18.0000] <caitp>
is there any reason why the single page version exists? you can't find anything on it anyway

[18:52:25.0000] <strugee>
are you talking about submission thing at the bottom?

[18:52:44.0000] <caitp>
99/100 times, cmd+f yields nothing useful

[18:53:25.0000] <caitp>
not that trying to find anything in the multipage version is any better

[18:53:39.0000] <caitp>
you need like a dxr for the spec

[18:54:44.0000] <strugee>
or we should put the built version in Git or something so you can grep it

[18:55:15.0000] <caitp>
eh but then i'd have to keep a fork of it

[18:55:40.0000] <strugee>
*shrugs* set up some automation

[18:57:57.0000] <Hixie>
we have a copy in git, for the record :-)

[18:58:01.0000] <Hixie>
on github

[18:58:12.0000] <Hixie>
why does cmd+f not work for you? is your browser broken?

[19:09:53.0000] <strugee>
all right, laptop's dying

[19:09:57.0000] <strugee>
Hixie: it's been a pleasure

[19:10:06.0000] <strugee>
I'll ping you on GitHub or something if I need anything else

[19:10:08.0000] <Hixie>
np. keep me posted about what you want.

[19:10:11.0000] <strugee>
thanks!

[19:10:53.0000] <caitp__>
it's not that the browser is broken, it's that A) the document is too large, B) there are too many references to key phrases, C) many of the references don't lead anywhere useful, or lead to the references section, which in turn leads nowhere useful

[19:10:59.0000] <caitp__>
it's basically organized really badly

[19:11:32.0000] <caitp__>
a dxr would help a lot

[19:11:52.0000] <caitp__>
cross referencing the referenced specs, and not all being a client-side operation

[19:11:58.0000] <caitp__>
would make it a lot easier to work with

[19:12:38.0000] <Hixie>
if there are problems, file bugs with concrete suggestions

[19:13:05.0000] <Hixie>
cos "it's basically organized really badly" is really unactionable given that i've spent the last 11 years organising it as best as i can :-)

[19:13:13.0000] <Hixie>
more or less full-time :-)

[19:13:24.0000] <caitp__>
"dxr" is a pretty concrete suggestion, I think

[19:13:42.0000] <caitp__>
server-side spec searching and cross-referencing, that's pretty concrete :p

[19:14:29.0000] <Hixie>
i've no idea what you mean by this

[19:14:51.0000] <caitp__>
huk

[19:15:29.0000] <caitp__>
okay so the classical example would be, suppose you had to load the entire source tree of chromium into your browser, formatted

[19:15:38.0000] <caitp__>
that would be a pretty big document, right?

[19:15:54.0000] <caitp__>
searching it would be hard, expensive, and most of the time wouldn't turn up anything particularly useful

[19:16:32.0000] <caitp__>
the spec is pretty big, searching it frequently turns up nothing useful

[19:17:08.0000] <caitp__>
so it would be nice to provide better ways of doing this, and even caching entries for common searches

[19:17:35.0000] <Hixie>
what are you talking about. searching the spec works great, i do it all the time.

[19:17:42.0000] <Hixie>
plus every term is cross-referenced in both directions.

[19:17:45.0000] <caitp__>
mmmm not so much

[19:17:48.0000] <Hixie>
with a little popup that shows all the references

[19:18:03.0000] <caitp__>
even doing something as simple as looking up interfaces takes way longer than it should

[19:18:09.0000] <Hixie>
and i've watched chromium developers, they basically use "grep" which is more or less the same as find-in-page

[19:18:19.0000] <Hixie>
there's an interface index

[19:18:22.0000] <caitp__>
grep is faster, but again, means keeping a fork

[19:19:36.0000] <Hixie>
grep is the same speed as find-in-page

[19:19:41.0000] <caitp__>
no it really isn't

[19:20:47.0000] <Hixie>
are you using some ancient browser or something?

[19:20:54.0000] <caitp__>
no

[19:21:33.0000] <caitp__>
I mostly  use canary on an 8 core machine, but it's not any better with stable, or safari 8, or FF nightly or stable

[19:21:52.0000] <caitp__>
it's a big document, it loads slowly, and referenced terms link nowhere useful, and unreferenced terms link nowhere

[19:22:08.0000] <caitp__>
it's not very usable for quickly looking something up

[19:22:30.0000] <caitp__>
and if I'm on a laptop, forget it =)

[19:22:37.0000] <Hixie>
for each "referenced terms link nowhere useful" case, file a bug.

[19:22:43.0000] <Hixie>
saying what you want it to link to.

[19:23:16.0000] <Hixie>
for "unreferenced terms" i've no idea what you mean

[19:23:19.0000] <caitp__>
they all lead to the references section, which means A) i lose my place which was very difficult to get to in the first place, and B) don't immediately link to anything useful, just a references section

[19:23:32.0000] <caitp__>
"unreferenced" eg, not in the references section, no popup, no hyperlink

[19:23:37.0000] <caitp__>
just text

[19:23:47.0000] <Hixie>
but for the original complaint, find in page... it's pretty much instantaneous for me. i don't understand the problem.

[19:23:50.0000] <Hixie>
how is grep faster?

[19:24:13.0000] <Hixie>
i've no idea what you mean by "they all lead to the references section"

[19:24:16.0000] <Hixie>
what is "all" here?

[19:24:36.0000] <Hixie>
i mean there's 4313 <dfn> elements in the document

[19:24:48.0000] <Hixie>
so quite obviously, not all the cross-references are to the references section

[19:24:50.0000] <Hixie>
in fact hardly any are

[19:24:53.0000] <caitp__>
I'm not sure what your language for it is, but a cross-referenced term is typically a link which opens a popup window, with links which lead to a references section at the bottom of the document

[19:25:05.0000] <caitp__>
and by "typically" I mean always, as far as I can tell

[19:25:13.0000] <Hixie>
can you give me an example?

[19:25:25.0000] <caitp__>
pretty much any time I find one, that's what happens :p

[19:25:31.0000] <Hixie>
ok find one

[19:25:32.0000] <Hixie>
tell me what it is

[19:25:38.0000] <Hixie>
i'm at a loss as to what you mean

[19:25:56.0000] <Hixie>
the only links into the references section i'm aware of are the [FOO] links

[19:26:10.0000] <Hixie>
which are, well, the links to the references section.

[19:26:23.0000] <Hixie>
and i don't think any of those do any popups or anything

[19:26:53.0000] <Hixie>
(there is an open bug on making them more helpful)

[19:42:22.0000] <caitp__>
i still prfer the dxr idea

[19:51:10.0000] <Hixie>
caitp__: can you give me an example of what you mean? what are these cross-references that aren't useful?

[19:51:42.0000] <caitp__>
i'm on my laptop, too much to open the single page site

[19:52:02.0000] <caitp__>
typical experience though, is looking up details on some attribute in an idl interface

[19:52:07.0000] <Hixie>
the multipage copy has the same links

[19:52:08.0000] <caitp__>
leads to a references link

[19:52:11.0000] <Hixie>
so feel free to give me the links from there

[19:55:01.0000] <MikeSmith>
I do searches in the single-page spec all the time but I do it from elinks

[19:55:08.0000] <MikeSmith>
or lynx

[19:55:45.0000] <MikeSmith>
but I guess that's not a general solution that a lot of other people would be happy with

[19:57:08.0000] <MikeSmith>
but I'll also agree that trying to load and use the the single-page rendered version in a real browser is not practical

[19:57:50.0000] <Hixie>
i mean, it's the only way i use the spec

[19:57:53.0000] <Hixie>
and i do it all the time

[20:16:02.0000] <zewt>
i find the multipage one unusable and always use the single page one (broken backrefs are a dealbreaker)

[20:16:50.0000] <MikeSmith>
I use a 4-year-old laptop most of the time so I guess I should get a faster machine

[20:22:30.0000] <caitp__>
i guess everyone has different experiences with it

[20:23:05.0000] <caitp__>
online search + fast loading smaller pages would go a long way though, i think

[20:24:33.0000] <Hixie>
MikeSmith: i mean, the desktop i use for this is from 2010...

[22:25:39.0000] <zewt>
why am i still using chrome? now it's saying "foo.zip may harm your browsing experience, so Chrome has blocked it", and it literally won't let me save the file

[22:26:26.0000] <zewt>
pretty unbelievable

[22:28:27.0000] <caitp__>
it just wants you to have the best browsing experience possible and gets a bit carried away

[22:28:54.0000] <zewt>
by making me download this file twice (because it already downloaded all of it, it just won't save it)

[22:29:13.0000] <zewt>
at least half a gig isn't as much as it used to be

[22:44:38.0000] <KevinMarks_>
Do any implementations of audio or video tags support media fragments in sources?

[23:00:17.0000] <annevk>
TabAtkins: well, DOM wasn't built in a day

[23:07:28.0000] <annevk>
/me uses single-page without a problem too, find in page combined with backreferences is pretty much all I use...

[23:37:30.0000] <TabAtkins>
strugee: Please dont' try and do text-based transforms on an HTML document.  Just use a real HTML parser and deal with it that way.  Python has html5lib; I'm unsure of what standards-compliant parsers exist in JS.

[23:43:48.0000] <annevk>
https://github.com/aredridel/html5 perhaps?

[23:52:44.0000] <Domenic>
Also parse5

[02:30:47.0000] <strugee>
TabAtkins: yeah, I'm off that train. Hixie talked me out of it

[02:31:02.0000] <strugee>
it wasn't that hard. I didn't hold out much hope that it could work anyway :)

[10:05:42.0000] <annevk>
Very hard not to 386 https://bugzilla.mozilla.org/show_bug.cgi?id=999544


2015-02-23
[22:57:55.0000] <annevk>
"typical imprecise-DOM-spec-type" lol Domenic, if anything is actually undefined you'll file a bug right?

[23:00:04.0000] <Domenic>
annevk: yeah... I don't think implementers won't get it, but it's just hard for me to trace when the word "this" is never actually said and it's all so implicit...

[23:00:47.0000] <annevk>
Domenic: it's not implicit, but if you still think that DOM would handle JS minutia you haven't really been paying attention... that's IDL

[23:01:20.0000] <Domenic>
annevk: I think "the associated list of event listeners" is pretty implicit.

[23:01:29.0000] <Domenic>
associated to what?

[23:03:21.0000] <annevk>
If used as mixin that might be unclear I guess

[23:03:40.0000] <annevk>
File a bug? Is it used as mixin anywhere?

[23:03:42.0000] <Domenic>
Or when it's on the prototype chain, especially when window vs. window proxy is involved.

[23:03:51.0000] <Domenic>
nah as i said i'm sure implementers are fine with it

[23:04:00.0000] <Domenic>
just not the level i'm used to

[23:04:21.0000] <annevk>
I don't see how WindowProxy matters here. No events are ever dispatched at it.

[23:04:58.0000] <Domenic>
consider `window.addEventListener("foo", ...)

[23:05:12.0000] <Domenic>
That invokes the method with `this` set to the WindowProxy, not to the Window

[23:05:19.0000] <Domenic>
Does WindowProxy have an associated set of event listeners?

[23:05:47.0000] <annevk>
I don't think so, it's not an EventTarget object either

[23:06:38.0000] <Domenic>
Why isn't it? Is there any test you could run on it that would allow you to say that it is not?

[23:06:39.0000] <annevk>
There's an open bug on IDL to define "this" and pass it on more clearly

[23:07:18.0000] <Domenic>
And if it doesn't have an associated set of event listeners, then how does addEventListener get "the" associated set of event listeners to operate on?

[23:07:57.0000] <annevk>
That might be a problem with the definition of Window/WindowProxy, sure

[23:08:19.0000] <annevk>
At this point DOM doesn't really have anything on those objects

[23:08:49.0000] <Domenic>
Well my point was more that if you said "the [[Events]] internal slot of `this`" then it would be much clearer what the answers to those questions are

[23:10:49.0000] <annevk>
Domenic: that is the defined behavior through "context object", for which I already mentioned that we asked IDL to make it explicit, at which point I'll probably start using it explicitly rather than omit it for brevity when it's clear from context

[23:11:18.0000] <annevk>
Domenic: I don't necessarily disagree with using slots instead, there's an open IDL bug on that too

[23:11:59.0000] <annevk>
Domenic: but that things are not defined in language you prefer doesn't make it imprecise, that would mean implementers could reach different conclusions from the same text at which point they'd file bugs etc.

[23:13:42.0000] <Domenic>
I think implementers could legitimately reach different conclusions about what "the associated set of event listeners" means in the context of window vs. window proxy

[23:13:55.0000] <Domenic>
And about the question of whether WindowProxy is an EventTarget object

[23:14:30.0000] <Domenic>
Anyway I didn't mean to pick a fight right before I had to sleep. More just was putting that there as a disclaimer that I might not be reading things right.

[23:14:32.0000] <annevk>
But why then claim that the DOM specification is unclear when it is in fact the specification for WindowProxy that is sorely lacking as we all already know?

[23:14:39.0000] <Domenic>
or at least, not reading things as they are intended

[23:15:01.0000] <Domenic>
I think the DOM spec could be made clearer independent of window vs. window proxy. Proxies are pretty well-defined behavior.

[23:15:14.0000] <Domenic>
"the associated set" is not well-defined.

[23:15:25.0000] <annevk>
It's the context object's associated set

[23:15:39.0000] <annevk>
So if the context object is WindowProxy as you say, that would be it

[23:16:08.0000] <Domenic>
I mean the definition of context object isn't exactly that clear either

[23:16:12.0000] <Domenic>
"on which something is being called"

[23:16:27.0000] <annevk>
That is fair, and as I said I'm waiting for an IDL fix

[23:16:57.0000] <annevk>
Because only IDL can set that parameter correctly based on the JS -> IDL -> spec -> IDL -> JS bridge

[23:17:08.0000] <Domenic>
Anyway, I need to head to sleep, sorry for the offhanded comment :-S

[23:26:57.0000] <zcorpan>
why is cssom access restricted to same-origin again?

[23:27:59.0000] <annevk>
zcorpan: euh, web security model?

[23:29:19.0000] <zcorpan>
annevk: you can get the computed style so the declarations leak anyway, and you can't get the original text since it's parsed and reserialized, so you can't read things that are not css

[23:30:29.0000] <annevk>
zcorpan: declarations of styles not applied don't leak, declarations of styles not applied depending on cookies don't leak, etc.

[23:31:45.0000] <zcorpan>
annevk: so having a secret in a selector

[23:34:07.0000] <annevk>
zcorpan: are we requiring text/css as MIME type these days? If servers can be tricked into using that MIME type for resources there might be other risks too

[23:35:14.0000] <zcorpan>
annevk: yes, except in quirks mode but that's only for same-origin stylesheets

[23:35:29.0000] <annevk>
zcorpan: we should not reduce the amount of protection the same-origin policy gives, the amount that CSS, images, and script leak today is sufficient

[23:36:15.0000] <annevk>
(well, too much really)

[23:36:54.0000] <zcorpan>
annevk: sure, i agree

[23:45:32.0000] <zcorpan>
i remember https://bugzilla.mozilla.org/show_bug.cgi?id=524223 but it didn't use cssom

[00:02:13.0000] <annevk>
zcorpan: that CSS loads across origins is a bug, restricting CSSOM is to some extent defense-in-depth and to some extent actually defends out-of-scope declaration blocks

[00:13:20.0000] <zcorpan>
annevk: thanks. https://lists.w3.org/Archives/Public/public-houdini/2015Feb/0053.html

[00:33:44.0000] <annevk>
zcorpan: don't we support CORS now for CSS loads?

[00:34:53.0000] <zcorpan>
annevk: the spec does, don't remember what is implemented

[00:35:00.0000] <annevk>
zcorpan: the other thing this is protecting of course is what CSSOM might become going forward; it would seem bad to forever constrain yourself by the current invariants

[00:36:49.0000] <zcorpan>
yeah

[00:37:11.0000] <annevk>
zcorpan: also, getComputedStyle requires brute-forcing to find all selectors as there's no other way to read them

[00:37:45.0000] <annevk>
zcorpan: coupled with varying media somehow, etc.

[00:38:04.0000] <annevk>
zcorpan: raw CSSOM exposes all trivially

[00:38:33.0000] <zcorpan>
yeah but it's still pretty trivial to do

[00:38:56.0000] <zcorpan>
varying media is more annoying

[00:54:21.0000] <Krinkle>
I'm not a 100% sure but I think I've seen some user extensions make use of CORS and CSS at Wikimedia.

[00:54:36.0000] <Krinkle>
To be able to inspect the loaded rules from a no-cookies domain

[00:57:57.0000] <annevk>
zcorpan: it would take quite some time

[01:01:46.0000] <zcorpan>
annevk: i'm writing a testsuite for the rendering section that basically does exactly this. i'm even checking :before and :after on each element. it's not taking that much time

[01:03:41.0000] <annevk>
zcorpan: euhm, you also need to generate all possible trees

[01:07:26.0000] <zcorpan>
annevk: yeah that will take infinite time, but you probably can get far by enumerating the most commonly used elements, classes and ids

[01:14:55.0000] <oenftw>
good morning, are there any benefits of using the HTML5 semantics?

[03:59:22.0000] <annevk>
zcorpan: maybe, but you'll get more with CSSOM which seems bad

[03:59:35.0000] <zcorpan>
annevk: yes

[07:14:57.0000] <aleray__>
hi, is it ok to use h1 inside <article> tags?

[07:15:09.0000] <annevk>
aleray__: yes

[07:15:17.0000] <aleray__>
annevk,thanks

[07:15:31.0000] <aleray__>
I had contradictory readings about that.

[07:16:05.0000] <annevk>
I think the model suggested by the specification does not have full support, which is why people might caution against it as a practical matter

[07:16:49.0000] <aleray__>
This text suggests the following for instance: http://html5doctor.com/the-article-element/

[07:17:07.0000] <aleray__>
in the "An <article> with comments as nested <article>s" section

[07:18:28.0000] <annevk>
aleray__: they don't recommend against it though, do they?

[07:18:56.0000] <annevk>
aleray__: they just have a header for the article rather than just a heading

[07:19:29.0000] <annevk>
aleray__: and actually, under "Using <article> for a widget" it seems to cover the case of using <h1> directly

[07:21:21.0000] <aleray__>
annevk, ok. Not sure to understand the subtlety. I will go through it again. In my case I have a div in which I list news. Each news is wrapped in an <article> and now has an h1 in it.

[07:21:47.0000] <annevk>
aleray__: sounds fine

[07:23:54.0000] <aleray__>
annevk, nice. My outline is wrong but I might have unclosed tags somewhere. Let's fix the structure first

[07:24:43.0000] <aleray__>
btw, just fyi I have just published https://github.com/aleray/html5lib_typogrify

[07:25:10.0000] <aleray__>
it is really minimal now, but if I have time I will expand it

[08:22:32.0000] <annevk>
JakeA: what does GPU-rendered DOM element mean?

[08:22:38.0000] <Ms2ger>
Nothing

[08:23:36.0000] <JakeA>
annevk: do the rasterisation on the GPU, like we do with canvas right now

[08:23:42.0000] <annevk>
JakeA: I think the main slowness people have with DOM, across both React and the Google components crowd, is that if you have a large mutating tree, layout gets slow. Both then take the approach of putting all the data outside the DOM and then stamping out something smaller based on what is seen by the user through a template of sorts...

[08:24:40.0000] <annevk>
JakeA: so that instead of a 10000 item list, you only have a list with 50 items that are seen by the user, backed by a 10000 item JavaScript array

[08:25:22.0000] <annevk>
JakeA: unless we can solve that scenario, the DOM seems rather doomed as information container

[08:26:19.0000] <JakeA>
annevk: wouldn't some layout feature make that ok in the DOM? Some kind of list-view display? I guess you could do that yourself with hooks into layout

[08:26:41.0000] <annevk>
JakeA: so this GPU-rendering of DOM elements is GPU-rendering of CSS "boxes"?

[08:26:41.0000] <Ms2ger>
xul:listbox

[08:27:28.0000] <annevk>
JakeA: well, what Polymer has is <core-list>, which has this JavaScript-backed thing

[08:27:30.0000] <JakeA>
annevk: Yeah

[08:27:39.0000] <annevk>
JakeA: ok that makes more sense

[08:29:01.0000] <annevk>
JakeA: a layout primitive goes some ways, though does not necessarily help with invalidation of trees due to mutation and selectors that then have to match again

[08:29:17.0000] <annevk>
JakeA: for that isolated styles could help

[08:29:46.0000] <annevk>
JakeA: wycats has some ideas around that, but nothing concrete

[08:30:22.0000] <annevk>
But it's a rather large gap to bridge and I can totally understand why we have these experiments going on to get it some other way

[08:32:17.0000] <annevk>
JakeA: anyway, this has annoyed me too, thanks for pushing people to dig a little deeper

[08:39:53.0000] <wycats>
annevk: which ideas?

[08:40:24.0000] <wycats>
JakeA: the biggest issue with list-view is the lack of scroll hooks

[08:40:36.0000] <wycats>
https://github.com/emberjs/list-view is used a lot in production Ember apps

[08:40:39.0000] <smaug____>
Ms2ger: I think you want xul:tree

[08:41:14.0000] <JakeA>
wycats: Chrome has been proposing a sync scroll handler (onbeforescroll) but I think it's getting push-back from other vendors

[08:41:16.0000] <annevk>
wycats: around isolation for CSS

[08:41:23.0000] <wycats>
JakeA: yeah

[08:41:51.0000] <wycats>
JakeA: I think we should provide it and accept that it forces us to think hard about keeping frames small

[08:41:52.0000] <JakeA>
annevk: yeah, I guess we need style resolution hooks and/or isolation

[08:42:02.0000] <wycats>
JakeA: Shadow DOM helps a lot here

[08:42:04.0000] <wycats>
especially for list views

[08:42:24.0000] <wycats>
unrelatedly, I just posted: https://twitter.com/wycats/status/569893045321101312

[08:42:31.0000] <JakeA>
wycats: agreed. Maybe sync handlers are bad but all the touch-event-based scroll reimlementations are way worse

[08:42:41.0000] <annevk>
JakeA: there's interest from Mozilla in solving the problem, though roc seems to prefer adding a UI-centric worker

[08:43:04.0000] <wycats>
JakeA: 100%

[08:43:06.0000] <annevk>
JakeA: see dev.platform thread I pointed to on Twitter

[08:43:08.0000] <wycats>
annevk: I need to speak to roc

[08:43:12.0000] <wycats>
I don't agree with him on that thread

[08:43:31.0000] <wycats>
(as a person who has implemented this stuff)

[08:43:31.0000] <wycats>
I don't mind creating a new UI daemon

[08:43:32.0000] <wycats>
but it's not tackling the problem head-on

[08:43:51.0000] <JakeA>
wycats: I think there are some oddities that make that not true. Maybe position:fixed inside that element? I can't remember. TabAtkins would know.

[08:43:51.0000] <annevk>
wycats: give it three-four hours and he might be online I guess, assuming he's at home

[08:44:00.0000] <wycats>
:)

[08:44:10.0000] <wycats>
the way to tackle the problem is to look at the 17ms timeslice, figure out where it's going, and figure out how to shrink it

[08:44:21.0000] <wycats>
and then figure out how to give developers APIs that don't blow the budget

[08:44:32.0000] <wycats>
people who are writing things like list-view are very very very good devs

[08:44:41.0000] <wycats>
they can color inside the lines if they had the tools

[08:46:07.0000] <jgraham>
annevk: You got time to look at https://critic.hoppipolla.co.uk/r/3216 ?

[08:46:23.0000] <annevk>
JakeA: btw, the DOM spec calls it the "node tree" if you want a different term

[08:46:39.0000] <annevk>
JakeA: https://dom.spec.whatwg.org/#node-tree

[08:47:25.0000] <annevk>
JakeA: the JavaScript community sometimes uses "DOM" as a term for everything not JavaScript, which has been confusing me at times

[08:48:05.0000] <JakeA>
annevk: node tree is a good name for it

[08:48:07.0000] <JakeA>
nice

[08:51:26.0000] <annevk>
https://twitter.com/getify/status/569902233262796800 lol who exactly has been swapping terms :p

[08:52:57.0000] <Ms2ger>
"DOM layout"?

[08:53:02.0000] <Ms2ger>
As opposed to what?

[08:54:07.0000] <annevk>
JakeA: if you haven't seen it, I recommend looking at https://speakerdeck.com/vjeux/react-css-in-js

[08:54:20.0000] <annevk>
JakeA: it's a really great introduction to everything that is wrong with CSS

[08:55:14.0000] <boogyman>
annevk: i would argue that understand the meaning of DOM is much more important than knowing the word-for-word translation of the acronym, which may be what you're all eluding to in the proposed "rename/remap".

[08:55:52.0000] <annevk>
boogyman: what is the meaning?

[08:57:19.0000] <boogyman>
In Kyle's tweets it appears he's pushing back against DOM meaning "Node Tree" or "Document Model Model" or whatever "DOM layout" means.

[08:58:31.0000] <annevk>
boogyman: yeah, as I said above that's fairly prevalent in certain circles, Kyle's claim it goes for all web developers I doubt, but it's common

[08:58:37.0000] <jgraham>
I've for-sure seen people say "DOM is slow" when they meant "some aspect of CSS/layout is slow"

[08:59:56.0000] <jgraham>
e.g. someone complaining that adding flexbox to 50 elements caused slowness that they could avoid by computing absolute positions for those elements

[09:03:58.0000] <boogyman>
Understand the point, but "computing abs.pos." tells me they are only targeting small set of the world, which in itself is not ideal.

[09:04:51.0000] <wycats>
annevk: I think there are better solutions than vjeux's

[09:04:56.0000] <wycats>
Ember is investigating ;)

[09:05:02.0000] <wycats>
but his articulation of the problem is good

[09:05:24.0000] <jgraham>
Right, it might be that the new thing they did was a terrible mess. But they piggybacked on the "DOM is slow" meme to air a complaint about a facet of the platform that is entirely unrelated to the DOM.

[09:05:54.0000] <wycats>
jgraham: confirm

[09:06:00.0000] <wycats>
also, most of the platform is tractabl

[09:06:04.0000] <jgraham>
So even if we solve the problem, people will go "oh, there's still a DOM so it's still going to be too slow"

[09:06:10.0000] <wycats>
even within the context of the existing programming model

[09:06:20.0000] <wycats>
I am pretty tired of the revolutionaries

[09:06:25.0000] <wycats>
"let's replace CSS with a constraint solver"

[09:06:31.0000] <wycats>
"let's replace CSS with inline styles"

[09:06:32.0000] <wycats>
etc.

[09:09:35.0000] <wycats>
I would be happy with identifying portable style boundaries and specifying them

[09:10:00.0000] <wycats>
and also identifying easy heuristics you can use to prune selectors you don't have to match for a given operation

[09:13:36.0000] <gsnedders>
CSPs are really easy to solve, though!

[09:13:56.0000] <gsnedders>
BUT WHAT CSP AM I REFERRING TO?! #OverloadedInitalismsAreFun

[09:20:22.0000] <Ms2ger>
The common salesman problem?

[09:24:33.0000] <jsx>
In @counter-style, <symbol> = <string> | <image> | <ident>

[09:24:43.0000] <jsx>
What would be an example for <ident>

[09:24:50.0000] <Ms2ger>
blah

[09:49:26.0000] <annevk>
wycats: yeah, not sure about the solution space, but mostly the "this is a problem and why" is really good and interesting

[09:50:51.0000] <annevk>
wycats: heh, there's a bit of XHTML 2.0 in everyone :p

[09:51:30.0000] <gsnedders>
Ms2ger: no, Communicating Sequential Processes, duh!

[11:10:33.0000] <wycats>
lol

[11:21:12.0000] <jamesr___>
wycats: you need position as well, i believe

[11:23:12.0000] <jamesr___>
wycats: or positioned descendants of the overflow:hidden things will influence the position of siblings

[11:24:08.0000] <jamesr___>
ah, i see this was already covered on twitter

[11:24:40.0000] <gsnedders>
jgraham: should we make the tree walker tests part of the parser tests? I mean they're guaranteed to fail if the identical parser test fails…

[11:24:53.0000] <gsnedders>
jgraham: so it seems kinda like they should be part of the same test

[11:30:44.0000] <wycats>
is position: relative sufficient?

[11:54:49.0000] <roc>
wycats: speak to me

[12:17:11.0000] <wycats>
roc: I am currently pair programming on Ember

[12:17:16.0000] <wycats>
but I will ping you when I have uno momento

[12:21:59.0000] <TabAtkins>
jsx: Hm, it's linking over to the wrong spec for <ident>, but that just means keywords.

[12:30:48.0000] <roc>
annevk: that css-in-js deck is nowhere near "everything that's wrong with CSS" :-)

[12:31:58.0000] <roc>
in fact, I quite like their approach of driving everything with JS and inline styles. I was just thinking recently that that seems like a good way to negate one of the performance issues of Web vs native --- selector matching and cascading

[12:36:17.0000] <TabAtkins>
Yeah, I think there's some really interesting ideas we can dig out of there for applying styles more locally.

[12:36:49.0000] <TabAtkins>
Rather than the big mishmash of global styles that CSS is today. ^_^

[12:37:27.0000] <annevk>
roc: haha, fair

[12:38:16.0000] <annevk>
roc: yeah, the tight coupling is really interesting, also how useless specificity is

[12:38:31.0000] <roc>
the deck kinda oversells "CSS in JS" though

[12:39:03.0000] <annevk>
Might be because React has that approach to all the things that are not JS

[12:39:12.0000] <roc>
they're not bypassing all of CSS, not by any means --- just part of the style system

[12:39:13.0000] <TabAtkins>
I'm almost certain that a mature version of that would reinvent some form of specificity, though.  You could probably get away with just a single explicitly-supplied number, though.

[12:39:46.0000] <TabAtkins>
Without it, you have to rely on temporal ordering of application, which is trickier to manage as you get more complex.

[12:40:24.0000] <annevk>
TabAtkins: yeah, I guess you want some of it, coupled with isolation it wouldn't be an issue

[12:40:29.0000] <Domenic>
roc: I think they are bypassing hte "cascading" and "sheets" parts of CSS :P

[12:41:03.0000] <roc>
Domenic: yeah, well, it turns out that despite the naming, most of CSS is actually not about that :-)

[12:41:17.0000] <TabAtkins>
I want to spend some time later this year thinking about this some more, and seeing what I can come up with.  More experiments in this area by the JS people will help.

[12:41:44.0000] <roc>
I don't think stylesheets are really helpful to people building these apps

[12:41:56.0000] <annevk>
TabAtkins: I expect that not solving this will halt work on shadow DOM and such as well

[12:42:01.0000] <TabAtkins>
Agreed; they're actually an anti-feature when you're trying to get composability.

[12:42:05.0000] <TabAtkins>
annevk: yup.

[12:42:05.0000] <annevk>
TabAtkins: maybe less so for custom elements

[12:42:30.0000] <roc>
when you're constructing lots of DOM nodes with JS, it makes sense to set style values explicitly from JS as well.

[12:42:38.0000] <annevk>
TabAtkins: but I'd like to see us sort out what the way forward is for React / Ember style applications before committing to shadow DOM

[12:43:00.0000] <annevk>
Maybe Bert Bos was right after all that you don't want HTML/CSS/JS for applications

[12:43:21.0000] <TabAtkins>
No, he was still wrong, because what you want is just JS. ^_^

[12:44:37.0000] <annevk>
I may have remembered http://www.w3.org/People/Bos/webapps.html and http://www.w3.org/People/Bos/webapps-proposal.html for more than they are

[12:44:42.0000] <annevk>
TabAtkins: heh

[12:46:42.0000] <roc>
I like having a proper mental image of Tab to associate with his messages

[12:46:50.0000] <TabAtkins>
roc: Same!

[12:46:52.0000] <roc>
still don't have Domenic :-(

[12:47:02.0000] <TabAtkins>
His Twitter image is accurate.

[12:47:17.0000] <roc>
by "image", I don't mean an image :-)

[12:52:17.0000] <annevk>
roc: do you have some data on how long the selector matching takes vs other parts of CSS?

[12:54:24.0000] <roc>
I don't, but it's definitely enough that people (in Gecko and Blink at least) spend a ton of work optimizing it

[12:56:07.0000] <roc>
e.g. we did some work a while back to ensure that modifying inline style rules doesn't require rerunning selector matching. That helped some cases a lot.

[12:56:27.0000] <wanderview>
roc: is this the motivation for scoped styles as well?  seems they have not worked out

[12:56:55.0000] <wanderview>
explicit inline styling being the extreme case of "scoped" styles

[12:58:12.0000] <roc>
wanderview: no. Scoped styles are a modularity mechanism.

[12:58:26.0000] <wanderview>
ok

[12:58:56.0000] <roc>
and actually quite a helpful one, I think. It's just that Blink chose not to implement them

[12:59:09.0000] <roc>
same for CSS variables

[12:59:14.0000] <wanderview>
just seemed it would reduce the node tree that could be selector matched

[12:59:39.0000] <roc>
yes, that it does, though I don't think we've fully optimized around that

[13:00:08.0000] <annevk>
does it? external selectors could still match

[13:00:17.0000] <annevk>
there's no isolation

[13:00:36.0000] <wanderview>
annevk: I meant for styles modified in the "scoped" style tag

[13:01:01.0000] <wanderview>
/me only understands about 5% of this stuff...

[13:04:47.0000] <roc>
annevk: changes to the DOM outside the scope can't change the results of selectors in the scoped styles

[13:04:58.0000] <annevk>
wanderview: hmm fair, I think the bottleneck is DOM mutations, but I don't actually know

[13:05:01.0000] <annevk>
roc: also fair

[13:05:49.0000] <annevk>
roc: I think Chrome killed variables because their code wasn't up to par, not because they don't want the feature

[13:06:26.0000] <roc>
that sounds harsh ... but yes

[13:06:27.0000] <annevk>
roc: <style scope> seemed more adversarial and had to do with shadow DOM, something we're not quite sure about

[13:06:56.0000] <annevk>
roc: heh, maybe I misremembered but I thought that's what they said on blink-dev

[13:07:20.0000] <jamesr___>
that seems accurate from what i remember

[13:10:47.0000] <wanderview>
roc: I like your distinction about applying styles manually to elements... that's essentially what a programmatic native UI API would do... vs CSS declarative usage

[13:11:02.0000] <roc>
exactly

[13:11:35.0000] <wanderview>
and applying styles manually seems like a tooling issue

[13:11:41.0000] <wanderview>
or framework issue

[13:13:41.0000] <roc>
having said that, some UI toolkits have adopted CSS as a declarative widget styling mechanism, so it's still helpful for some apps. And it's definitely helpful for more document-like pages.

[13:14:50.0000] <roc>
another major source of overhead is the content/presentation distinction, which forces browsers to create a parallel tree of CSS boxes, using a sometimes expensive algorithm

[13:15:11.0000] <roc>
that seems harder to get around...

[13:15:30.0000] <dglazkov>
the premise of Shadow DOM is that you can have use CSS as it was designed, but break it up into smaller, per-component chunks

[13:16:09.0000] <roc>
even when we create anonymous boxes, in Gecko we create anonymous elements to back them up, because it's far too much trouble to support naked CSS boxes

[13:16:11.0000] <dglazkov>
at least in my observation, this leads to much simpler selectors

[13:16:38.0000] <dglazkov>
applying all CSS inline should be a valid choice for frameworks

[13:16:51.0000] <dglazkov>
but we as a platform can do better

[13:17:04.0000] <dglazkov>
in terms of primitive ergonomics

[13:18:26.0000] <dglazkov>
re: style scoped: https://groups.google.com/a/chromium.org/d/topic/blink-dev/JB8nFQXhAuQ/discussion

[13:20:28.0000] <wycats>
"but we as a platform can do better" big confirm

[13:26:01.0000] <dglazkov>
having Shadow DOM is style boundary also a pretty useful thing (without shadow-piercing combinators)

[13:26:14.0000] <dglazkov>
you could actually start computing style in parallel, for example

[13:28:06.0000] <dglazkov>
and of course, the shadow root being a natural style invalidation root is a good thing

[13:33:17.0000] <TabAtkins>
roc: We're nearly done with our parser rewrite, and then Variables is getting put right back in.

[13:37:34.0000] <wycats>
dglazkov: +1

[13:37:37.0000] <wycats>
TabAtkins: +1

[13:38:01.0000] <wycats>
TabAtkins: I think you really want the ability to give a component a stylesheet that gets its variables from custom properties

[13:38:16.0000] <wycats>
component.stylesheets.push(stylesheet)

[13:38:21.0000] <TabAtkins>
Yeah, variables inherit.

[13:38:27.0000] <wycats>
hm

[13:38:29.0000] <wycats>
say more

[13:38:41.0000] <wycats>
so the component itself would have some variables declared in the top-level sheet

[13:38:44.0000] <TabAtkins>
Custom properties inherit by default. So you can set them from outside the component, and use them inside the component.

[13:38:50.0000] <wycats>
sorry some custom properties

[13:38:52.0000] <wycats>
iiiiinteresting

[13:39:09.0000] <wycats>
so stylesheets.push, if implemented, would "just work"

[13:39:31.0000] <TabAtkins>
Yeah.

[13:39:34.0000] <wycats>
nice

[13:39:40.0000] <wycats>
please do implement

[14:05:57.0000] <dglazkov>
wycats: I want that too. I started a discussion a while back, but sadly I got distracted: https://lists.w3.org/Archives/Public/www-style/2012Oct/0491.html

[14:13:23.0000] <dglazkov>
And when I say "I", I mean "Tab".

[14:13:31.0000] <dglazkov>
:P

[14:15:14.0000] <jgraham>
Apropos nothing in particular, I was talking to someone that works on gaia today and it seems like they didn't think web components was going to provide the level of encapsulation they wanted for building FirefoxOS apps (aka web apps)

[14:17:36.0000] <dglazkov>
jgraham: would love to know more details there

[14:18:40.0000] <dglazkov>
it's a very generic statement :)

[14:20:22.0000] <jgraham>
dglazkov: Yeah, I don't want to give some false statement about what they wanted

[14:20:35.0000] <jgraham>
So I guess I should try to get them to give feedback directly

[14:20:38.0000] <dglazkov>
jgraham: anyone I could talk to?

[14:20:47.0000] <dglazkov>
I don't bite

[14:20:51.0000] <dglazkov>
anymore

[14:21:36.0000] <dglazkov>
:)

[14:23:30.0000] <jgraham>
It wasn't exactly clear to me what they did want, but they were talking about a solution that had multiple documents which is apparently good if you want to destroy one piece and reclaim all the memory, and allows building a clear message-based API

[14:24:02.0000] <jgraham>
I'm not really sure if/how this solved problems relating to styling

[14:25:28.0000] <jgraham>
(to be fair their solution didn't sound very sane to me, so as you can tell I am not a great proxy here)

[14:27:40.0000] <dglazkov>
:-\

[14:28:08.0000] <dglazkov>
maybe we could meet with them and try to have a brainstorm or something? Sounds like they're in a crazypants land

[14:29:07.0000] <smaug____>
well, separate docs especially from different domains give you rather good encapsulation ;)

[14:34:24.0000] <jgraham>
dglazkov: I'll see if there's someone who can provide actual useful feedback

[14:42:42.0000] <TabAtkins>
dglazkov: You're not at your desk, so... do we still have a flag for resetting inheritance on the shadow tree?  Or do you need to use a dummy element with 'all'?

[14:53:08.0000] <Domenic>
I was very disappointed in `all: unset`. It was too much. I think I want `all-but-display: unset`. I dunno, maybe it's workable in combination with a list of default-block elements.

[14:54:45.0000] <Domenic>
I was very disappointed in `all: unset`. It was too much. I think I want `all-but-display: unset`. I dunno, maybe it's workable in combination with a list of default-block elements.

[15:09:04.0000] <dglazkov>
TabAtkins:

[15:10:26.0000] <dglazkov>
TabAtkins: no flag. Must use 'all'.

[15:12:51.0000] <dglazkov>
jgraham: thanks!

[15:15:57.0000] <gsnedders>
jgraham: thoughts on html5lib question above?

[15:17:09.0000] <jgraham>
gsnedders: I don't think it's worth changing.

[15:18:36.0000] <gsnedders>
jgraham: (the stuff I'm doing as part of the expected failures and skipped tests etc. is rewriting all this anyway)

[15:19:18.0000] <smaug____>
jgraham: how do I check where and why certain wpt test was added

[15:20:16.0000] <jgraham>
gsnedders: I don't really care either way. I would err on the side of changing less, but if you think it's a big win that's fine

[15:20:30.0000] <jgraham>
smaug____: Look in the git history?

[15:21:24.0000] <smaug____>
like where? :)

[15:21:36.0000] <smaug____>
/me wonders what window-named-properties-001.html is about and why it would be valid

[15:24:44.0000] <jgraham>
smaug____: git clone https://github.com/w3c/web-platform-tests.git

[15:25:29.0000] <jgraham>
Author: Yuta Kitamura <yutak⊙gc>

[15:25:30.0000] <jgraham>
Date:   Fri Jun 21 13:49:27 2013 +0900

[15:26:26.0000] <jgraham>
So it's getting on for two web-component years old. Which are like 14 internet years, or 98 real years

[15:29:09.0000] <smaug____>
thanks

[15:30:54.0000] <gsnedders>
I'm running Firefox on Arch Linux, using the provided package. Firefox is reporting the Flash plugin as being out of date (11.2.202.440), yet looking at the so it's claiming to load it's 11.2.202.442. Any idea what's going on here? https://www.adobe.com/software/flash/about/ claims I have 11.2.202.442 too. (#firefox came up with the useful suggestion of removing Flash…)

[15:35:02.0000] <jgraham>
gsnedders: Step 1) Convince BBC to stop using Flash for iPlayer. Step 2) There are no remaining use cases for Flash so remove it with fire. Step 3) There is no step 3)


2015-02-24
[17:07:53.0000] <TabAtkins>
Domenic: You want "all: default;", which I need to go spec.

[17:08:04.0000] <TabAtkins>
Which means "pretend only the UA stylesheet exists".

[17:10:44.0000] <Domenic>
TabAtkins: meh, what I want is more like "all: like-ye-old-reset-stylesheet". i.e. no margins or padding or font size adjustment.

[17:11:01.0000] <TabAtkins>
You're not getting that, because it's opinionated in a weird way.

[17:11:37.0000] <TabAtkins>
"do what the UA stylesheet does" is simple and easy to talk about, and has a useful purpose in returning you to the "clean slate" that you started the page with.

[17:11:46.0000] <Domenic>
yeah, I agree.

[17:12:05.0000] <Domenic>
I was just sold for a long time that all: reset was going to replace my reset stylesheets, by parties unknown. it turned out to be false.

[17:12:19.0000] <TabAtkins>
Depends on what your reset stylesheets do.

[17:12:36.0000] <TabAtkins>
all: default; will replace your normalize.css. ^_^

[19:09:21.0000] <JonathanNeal>
Death to normalize.css! And anyone who ever contributed to it.

[19:13:22.0000] <caitp>
well that seems a bit harsh

[19:39:49.0000] <roc>
gsnedders: ask on mozilla IRC instead?

[19:46:38.0000] <roc>
I mean, #developers, not #firefox

[19:46:49.0000] <roc>
or try it in a clean profile

[20:46:53.0000] <JonathanNeal>
caitp: it was a joke

[23:45:52.0000] <karlcow>
CSSOM and resize https://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1061.html

[00:48:15.0000] <annevk>
Glenn Adams still hasn't fixed the CSSOM bugs? Shocker

[02:03:20.0000] <zcorpan>
didn't ie drop resize on elements recently?

[02:03:39.0000] <zcorpan>
seems like a good time to spec it

[02:06:59.0000] <annevk>
hah

[02:07:44.0000] <Ms2ger>
Morning zcorpan

[02:07:52.0000] <zcorpan>
good morning

[02:08:14.0000] <Ms2ger>
Your chocolate should be underway today

[02:08:38.0000] <Ms2ger>
In the meantime, want to do some reviews? :)

[02:08:44.0000] <zcorpan>
ooooh

[02:23:32.0000] <jgraham>
Ms2ger: Well played :)

[03:55:47.0000] <JakeA>
TabAtkins: what do you think of a :tab-focus pseudo to specifically target keyboard focuses?

[03:56:15.0000] <JakeA>
I find myself calling .blur() on something after mouse/touch to avoid buttons looking "stuck"

[03:56:28.0000] <JakeA>
which is obviously bad for a11y

[04:16:14.0000] <annevk>
JakeA: are you solving a CSS problem with blur()?

[04:16:41.0000] <annevk>
JakeA: isn't this why CSS gives you control over outline?

[04:20:48.0000] <JakeA>
annevk: I want my buttons/links to have a focus style so they can be tabbed through, but when they're clicked I don't want the button to appear "stuck" due to the focus style

[04:22:08.0000] <JakeA>
annevk: Firefox doesn't focus buttons on click, but it does for tabindex elements & links. Chrome focuses anything on click that can receive focus. Safari   doesn't focus links on click but will focus tabindex elements… it's a bit of a mess

[04:23:05.0000] <annevk>
UI input is a topic standards cover very poorly

[04:23:14.0000] <JakeA>
Tbh, I like the model of focus-on-click, because I'd expect the next tab to go to the tabbable element after the one I clicked, but the styling gets in the way

[04:23:23.0000] <annevk>
but thanks for explaining, :tab-focus makes sense

[06:14:33.0000] <annevk>
JakeA: what are the chances of Google following if we shipped proposal 3 from https://github.com/slightlyoff/ServiceWorker/issues/566 ?

[06:15:21.0000] <annevk>
JakeA: I sort of stopped caring about this when nobody wanted to give up scopes, but others do so I'll proxy

[06:18:20.0000] <JakeA>
annevk: I thought the conclusion of our meeting was that multiple scopes aren't needed, but it'd be nice to be able to change scopes in the activate event?

[06:19:11.0000] <annevk>
JakeA: the meeting summary suggests multiple scopes was very much on topic?

[06:20:57.0000] <JakeA>
annevk: yeah, my misremembering, sorry. I think we're still lacking good example cases where this is needed, but at least we have a way to add it without breaking compat

[06:21:24.0000] <annevk>
JakeA: so changing scopes would probably be okay as is? But multiple scopes would be more contentious?

[06:23:13.0000] <annevk>
And opting into fetch events seems contentious as well...

[06:23:21.0000] <annevk>
Sorry, opting out

[06:23:43.0000] <JakeA>
annevk: I think multiple scopes are the most contentious bit

[06:23:57.0000] <annevk>
ta

[06:24:01.0000] <JakeA>
which bit are Moz most interested in, or is it all of it?

[06:24:32.0000] <annevk>
I'm not sure, Ehsan asked about proposal #3 so I'll let you know when I know more

[06:24:46.0000] <annevk>
Some of Moz are interested in dropping all scopes still :p

[06:25:13.0000] <annevk>
(but they have also admitted defeat, don't really want to scare anyone)

[06:27:11.0000] <JakeA>
yeah, scopes have been really useful when it came to hosting on things like github & local servers

[06:27:57.0000] <annevk>
I don't disagree with that, but they're tacked on rather than a boundary which is the part that's wrong

[06:34:37.0000] <JakeA>
annevk: have you seen https://github.com/slightlyoff/StorageDurability/blob/master/explainer.md before? Who'd be good to get involved at Mozilla? We need something to achieve storage persistence, and I quite like the simplicity of this one

[06:47:56.0000] <annevk>
JakeA: probably the same people as SW

[06:49:14.0000] <annevk>
JakeA: the "What's All This About?" is rather Chrome-centric

[06:49:47.0000] <annevk>
JakeA: nobody else cared about that filesystem API and I'm not sure what it has to do with storage durability...

[06:51:58.0000] <JakeA>
annevk: yeah, I'm not sure what the onsync thing is either

[06:52:52.0000] <JakeA>
I'd rather it kept to one method

[07:34:46.0000] <annevk>
JakeA: is this replacing the evicted stuff?

[07:37:08.0000] <JakeA>
annevk: I still think those are useful, but we sorely need storage persistence, so I'm willing to move anything more complicated to "v2"

[07:38:02.0000] <wanderview>
annevk: you mean the onevicted event in SWs? I seem to recall some issue about that

[07:38:11.0000] <annevk>
I still think we should just provide everyone persistent storage

[07:39:01.0000] <annevk>
Plus heuristics, plus some kind of eviction...

[07:39:17.0000] <JakeA>
annevk: it's tough to put the user in charge of "uninstalling" things they didn't "install"

[07:39:19.0000] <annevk>
JakeA: this SD proposal also seems to assume the quota API is a thing we want

[07:39:28.0000] <wanderview>
I guess the hard part is determining who might be a bad actor in the system... who is using an unfair share of disk space blocking others from using it

[07:39:43.0000] <annevk>
JakeA: perhaps it's only really persistent if you bookmark

[07:40:09.0000] <wanderview>
annevk: do the specs have the concept of bookmarks, or is that a UA concept?

[07:40:21.0000] <JakeA>
annevk: I think bookmarking can auto-grant the permission, but I still think we need the permission

[07:41:08.0000] <wanderview>
JakeA: reading your comment about `navigator.requestStorageDurability()` I wondered... wouldn't everyone just call this?  why wouldn't they call it?

[07:41:20.0000] <annevk>
wanderview: it would be a UA concept

[07:41:22.0000] <wanderview>
is the idea that it creates a doorhanger or something?

[07:41:39.0000] <JakeA>
The idea is to allow a web user to safely cache 10gb of movies for a flight, without visiting another origin as they board the plane which puts their system under pressure and the browser throws everything away

[07:42:05.0000] <JakeA>
wanderview: it would show up a permission request

[07:42:31.0000] <annevk>
So many prompt designs :-(

[07:42:52.0000] <wanderview>
yea... if every page wants this for its 100kb of "essential" data... thats gonna be a lot of prompts

[07:42:53.0000] <annevk>
The user will have to click through an enormous amount of dialogs this way

[07:43:16.0000] <wanderview>
what about the call taking a size limit... durable up to this amount... UA can auto-grant permission for sizes less than X

[07:43:21.0000] <annevk>
notifications / storage / push / background / geolocation / ...

[07:43:43.0000] <annevk>
wanderview: well, UAs can always have better heuristics I suppose

[07:43:58.0000] <JakeA>
wanderview: that's the quota API isn't it? I thought the feeling was that size is too difficult to communicate to users

[07:43:59.0000] <annevk>
wanderview: I think we've lost the moment we ask the user for a specific amount of storage

[07:44:22.0000] <wanderview>
hmm

[07:44:38.0000] <JakeA>
annevk: Chrome already rolls notification & push into one permission request

[07:44:46.0000] <wanderview>
what about making all storage up to X durable by default... this API request is just for storage above X and does trigger a prompt

[07:44:49.0000] <JakeA>
if you request push, you get notificaitons

[07:44:52.0000] <wanderview>
so vast majority of websites don't need it

[07:45:44.0000] <wanderview>
maybe this is already whats there

[07:46:04.0000] <annevk>
JakeA: but Chrome has a distinct one for background push?

[07:46:25.0000] <annevk>
JakeA: (with background above I meant sync)

[07:46:37.0000] <JakeA>
annevk: hasn't been worked out yet

[07:46:43.0000] <annevk>
JakeA: right...

[07:47:15.0000] <annevk>
wanderview: we already have a quote of 10MiB or some such per eTLD+1

[07:47:22.0000] <annevk>
wanderview: quota

[07:47:35.0000] <annevk>
wanderview: and I think Firefox at some point had a prompt design

[07:47:38.0000] <wanderview>
annevk: in a spec or gecko?

[07:47:54.0000] <wanderview>
this needs to be consistent across browsers so web developers can design sane offline apps

[07:47:58.0000] <wanderview>
it seems to me

[07:48:14.0000] <annevk>
wanderview: https://html.spec.whatwg.org/#disk-space-2

[07:48:17.0000] <JakeA>
annevk: it has/had an appcache prompt

[07:48:40.0000] <annevk>
JakeA: well that too, but I thought there was something around storage

[07:48:41.0000] <wanderview>
annevk: we have persistent, temp, and default storage...  the spec stuff I've seen does not have the concept of "default" storage

[07:48:46.0000] <annevk>
or maybe that was Opera... hmm

[07:49:06.0000] <annevk>
HTML has "A mostly arbitrary limit of five megabytes per origin is suggested. Implementation feedback is welcome and will be used to update this suggestion in the future."

[07:49:46.0000] <wanderview>
yea

[07:49:48.0000] <JakeA>
As a user, if my device comes under storage pressure, I wouldn't expect to see things in the disk-usage menu that I hadn't 'added' somehow

[07:49:59.0000] <wanderview>
fun that its uncompressed size :-) I've been compressing in Cache

[07:51:15.0000] <wanderview>
also... uncompressed size for quota... just seems terrible for the user

[07:51:53.0000] <JakeA>
agreed

[07:51:55.0000] <wanderview>
JakeA: is there anything that prevents ad iframes from requesting these perms on every page visit?

[07:52:10.0000] <JakeA>
wanderview: generally we don't let iframes request permissions

[07:52:10.0000] <wanderview>
I seem to recall we had a problem with that and the contacts perm request in fxos

[07:52:13.0000] <annevk>
If I frequently visit something or have it bookmarked I would be quite happy if things got stored without anyone bothering me about it...

[07:52:20.0000] <JakeA>
since it doesn't tally with the url the user can see

[07:52:40.0000] <annevk>
wanderview: I wouldn't get hung up on compressed vs uncompressed, that should all really be up to the UA and we shouldn't really have to expose that

[07:52:55.0000] <wanderview>
yea

[07:52:59.0000] <annevk>
wanderview: although maybe at some point people don't want to see things compressed twice or some such... so we might add more control then

[07:53:11.0000] <wanderview>
annevk: I think the UA should be smart enough to do that

[07:53:11.0000] <JakeA>
annevk: yeah, bookmark or add-to-homescreen should auto-grant I think

[07:54:54.0000] <JakeA>
The UA could even auto deny the permission on things like first visit

[07:55:34.0000] <wanderview>
I wonder if the UA could do a dynamic heuristic like... auto-grant the durable permission at first... when the page actually breaches limit X, then place the door hanger... to avoid overwhelming the user with prompts

[07:56:26.0000] <wanderview>
I guess it comes down to when the API tells the page it officially has the storage or not

[07:59:02.0000] <annevk>
wanderview: might get problematic

[07:59:13.0000] <annevk>
wanderview: fairly simple app, large video file, boom

[07:59:53.0000] <wanderview>
annevk: why is that a boom?  prompts, user says yes or no...

[08:00:21.0000] <annevk>
wanderview: oh right, it can still store it but it might not be persistent

[08:00:24.0000] <annevk>
wanderview: sorry

[08:00:35.0000] <annevk>
wanderview: yeah might be okay

[08:01:07.0000] <wanderview>
with limited disk space... seems like we need a cooperative system... but of course the web is full of evil people

[08:02:47.0000] <annevk>
well the end goal is that the browser gets the whole hard drive

[08:02:54.0000] <annevk>
which is not super limited

[08:03:05.0000] <wanderview>
annevk: on mobile it is

[08:03:29.0000] <annevk>
low end, true, high end, less so

[08:03:53.0000] <annevk>
but yeah, that's why we need to give users insight into storage used

[08:04:18.0000] <annevk>
improving UI around this seems like it should be priority 1

[08:04:34.0000] <annevk>
because if that's unclear while we start handing out persistent storage we got a real mess

[08:20:21.0000] <wanderview>
I think low end mobile is what we should design... if we don't think disk is a limited resource then we should just not bother with any of this

[08:27:59.0000] <annevk>
wanderview: well I think we need to handle full disk

[08:28:21.0000] <annevk>
wanderview: and let the user manage storage

[08:28:36.0000] <annevk>
wanderview: those are all things we could do before we attempt persisting

[08:28:51.0000] <wanderview>
annevk: I agree we need it because storage is a limited resource (especially on mobile) :-)

[08:58:41.0000] <Domenic>
Is there any way to create an ArrayBuffer whose backing memory is composed of several other array buffers?

[09:09:18.0000] <paul_irish>
I'm trying to quiet the console spam in Chrome around "invalid" mimetypes.  I want to validate that specs do not have normative mimetype requirements for stylesheets, images, and fonts.

[09:10:16.0000] <Domenic>
paul_irish: I think per recent discussions in this channel, stylesheets have normative requirements. annevk was mentioning it IIRC?

[09:11:18.0000] <gsnedders>
paul_irish: most of the time the behaviour is undefined

[09:11:53.0000] <gsnedders>
CSS de-facto has to be loaded with the right mime type (at least cross-origin), because of data-leakage attacks

[09:11:59.0000] <annevk>
paul_irish: arguably HTTP requires resources to have valid MIME types

[09:12:13.0000] <annevk>
paul_irish: however, browsers do not enforce MIME types for images, stylesheets, and scripts

[09:12:27.0000] <annevk>
paul_irish: oops, they do for stylesheets, not for fonts

[09:12:40.0000] <gsnedders>
annevk: stylesheets I think same-origin in quirks you can use whatever

[09:13:04.0000] <annevk>
gsnedders: yup

[09:13:42.0000] <paul_irish>
for stylesheets i looked at the impl in blink.  it we would silently fail if its cross-origin, there is no text/css or "" empty mimetype, and the payload doesn't start with valid CSS.

[09:14:19.0000] <paul_irish>
but outside of those 3 constraints, it's good

[09:15:28.0000] <annevk>
it should fail same-origin as well I think in standards mode

[09:15:51.0000] <annevk>
dunno if empty MIME type matches the spec

[09:15:53.0000] <annevk>
offhand

[09:16:35.0000] <paul_irish>
k. thanks

[09:17:33.0000] <annevk>
paul_irish: if the metrics show that over time more people use correct MIME types the console spam may be worth it

[09:18:12.0000] <annevk>
paul_irish: the current model is rather prone to attacks

[09:18:42.0000] <paul_irish>
<img src="evil.js"> ?

[09:51:39.0000] <annevk>
paul_irish: more like <script src=image>

[09:51:50.0000] <paul_irish>
gotcha

[09:52:18.0000] <annevk>
paul_irish: basically a mismatch between what the server thinks the file can be used for and what the browser allows

[09:52:45.0000] <annevk>
paul_irish: sniffing is defined and it's somewhat clear to server operators these days not a lot can be trusted, but if we could improve that'd be nice

[09:53:02.0000] <annevk>
Domenic: I think only Blob supports that...

[09:53:22.0000] <annevk>
Domenic: also, that seems more like a feature for views than the buffer...

[09:55:59.0000] <Domenic>
annevk: meh not sure why it would be. I have several arraybuffers and I want to concatenate them with a transfer instead of copy.

[09:56:26.0000] <annevk>
Domenic: there's a proposal for transfer I think

[09:56:46.0000] <Domenic>
annevk: yep, that's where I came from actually. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer/transfer

[09:57:01.0000] <Domenic>
We're thinking of using transfer for byte streams

[09:57:11.0000] <Domenic>
but we still have a use case where people want to read an entire stream into one big array buffer

[09:57:26.0000] <annevk>
I'd like some syntax for ArrayBuffer so you can do AB1 + AB2

[09:57:38.0000] <Domenic>
i think it's OK to say people have to do that manually though, and/or wait for an ES7 combiner method

[09:59:23.0000] <wanderview>
does it really matter how the ArrayBuffer stores it in memory if there is an API to create an AB from multiple other ABs?

[10:00:48.0000] <Domenic>
wanderview: I just want no-copies guaranteed, not sure whether I care about how it's stored.

[10:03:32.0000] <wanderview>
Domenic: well, no-copy means multiple segments if you have multiple sources :-) feedback from people in the room with me is that multiple segments is harder to do and also keep the various view classes fast

[10:03:45.0000] <Domenic>
interesting

[10:04:21.0000] <wanderview>
for example if your UInt16 crosses segment boundaries or something... now you can't just simple processor primitives... you have to additional logic in the path

[10:04:39.0000] <wanderview>
it seems possible... but sounds like there would be push-back

[10:55:54.0000] <rillian>
so, the media element resource selection algorithm says the user agent will discard <source> elements whose type attributes it knows it cannot play

[10:56:07.0000] <rillian>
I assume that means canPlayType() == ''

[10:57:01.0000] <rillian>
but there seems to be no coupling to the actual resource load

[10:57:24.0000] <rillian>
so the type attribute can be pure fiction outside of the 'I know I can't play that' constraint

[10:57:27.0000] <rillian>
is that correct?

[10:58:14.0000] <rillian>
I ask because imgur.com's new gifv service makes pretty markup with webm and mp4 source links...and serves video/mp4 to for both resources.

[10:59:30.0000] <TabAtkins>
I think so, yeah.

[11:01:34.0000] <rillian>
ok, so all that careful arguing we did for page control of which resource to load...not so much :(

[11:52:17.0000] <zewt>
sounds like the usual "seems to work" that everything on the web falls into when you have variable behavior

[12:45:14.0000] <annevk>
rillian: the page does control what to load, no?

[12:46:24.0000] <annevk>
rillian: I'm not sure if it's all browsers yet, but the MIME type stated by the server is ignored, I believe, but the MIME type stated by the page is used for negotiation by browsers

[13:26:49.0000] <rillian>
annevk: I'm not sure that's true

[13:27:42.0000] <rillian>
I mean, I hope we reject sources with types we can't play

[13:27:59.0000] <rillian>
but we accept sources whose actual type doesn't match their declared type

[13:28:05.0000] <Domenic>
Are 304s still transparent to fetch? Or is there some fromCache flag?

[13:28:50.0000] <rillian>
I fear without that kind of enforcement the type attribute on <source> is as moot as the type from the server

[13:29:31.0000] <TabAtkins>
rillian: The 'enforcement' is "the browser won't play it if it doesn't know that the type attribute specifies something it can play".

[13:35:03.0000] <rillian>
TabAtkins: the spec says "A type that the user agent knows it cannot render" which is the opposite

[13:35:14.0000] <rillian>
perhaps because of the whole 'maybe' thing with canPlayType?

[13:35:25.0000] <TabAtkins>
Sorry, I got lost in the negations.  Obviously I mean the other way. ^_^

[13:35:33.0000] <rillian>
heh

[13:36:37.0000] <rillian>
anyway, this is just me failing to not say 'I told you so'. It is what it is.

[13:36:56.0000] <rillian>
I was just sad that it's possible to totally lie about the type attribute

[13:37:20.0000] <rillian>
lie *with* the type attribute on <source>

[13:44:18.0000] <TabAtkins>
Eh, turns out type-sniffing video is just easier and more reliable for everyone.

[13:46:45.0000] <TabAtkins>
The only real reason to declare the type is to avoid retrieving anything at all when we can tell ahead of time that it definitely won't work, which is precisely what it does.

[14:02:33.0000] <annevk>
Domenic: there's various open issues around caching

[14:12:00.0000] <Domenic>
annevk: use case: trying to adaptively estimate download speeds and use that to choose quality for future video downloads, but want to eliminate outliers caused by caching returning very fsat

[14:15:05.0000] <annevk>
Domenic: the outstanding issues are primarily around security and a good model for partially cached resources

[14:15:13.0000] <annevk>
Domenic: it's clear that exposing this would be useful

[14:15:28.0000] <annevk>
Domenic: see bugs on Fetch and various issues scattered around GitHub

[14:15:31.0000] <Domenic>
ah yeah security fun times

[14:15:47.0000] <Domenic>
yeah it sounded familiar just kind of remembered it being resolved by now

[14:16:49.0000] <annevk>
Domenic: there's bits in the spec

[14:17:14.0000] <annevk>
Domenic: the partially cached stuff is still somewhat broken, I forgot why fromCache hasn't been added yet

[14:17:35.0000] <annevk>
Domenic: perhaps I was waiting for feedback on the general design of things first and some answer about how to handle partial caches

[14:17:40.0000] <annevk>
Domenic: it's all in the issues somewhere

[14:18:16.0000] <annevk>
https://lists.w3.org/Archives/Public/www-international/2015JanMar/0080.html "Do not interpret my comments as an attack on the author." trololol

[14:35:19.0000] <Domenic>
O_O

[14:38:20.0000] <TabAtkins>
Glenn "I've never made a nontrivial edit to the only CSS spec I maintain" Adams

[15:12:00.0000] <MikeSmith>
that nickname's probably too long for him to fit on his business card

[15:12:34.0000] <MikeSmith>
so probably need to do some brainstorming to help him come up with a shorter nickname

[15:13:12.0000] <dglazkov>
don't be mean to folks :)

[15:13:45.0000] <MikeSmith>
hey I'm just trying to be helpful here

[15:14:07.0000] <MikeSmith>
anyway, speaking of helpful, "Waiting for available socket"

[15:14:36.0000] <MikeSmith>
I seem to be getting that message in Chrome oftenish these days

[15:15:13.0000] <MikeSmith>
or more accurately, in Chromium, built from trunk

[15:15:45.0000] <MikeSmith>
I got a lot of tabs open but I wouldn't think that would cause it

[15:15:53.0000] <MikeSmith>
also, this is on OSX

[15:16:22.0000] <caitp->
i've seen that a few times before, on stable builds afaik

[15:16:28.0000] <MikeSmith>
ah OK

[15:16:43.0000] <MikeSmith>
well to be clear when it happens, the page load just hangs

[15:16:52.0000] <MikeSmith>
or I mean the response never comes at all

[15:16:57.0000] <caitp->
yeah

[15:17:32.0000] <MikeSmith>
I seem to be getting it when trying to load *.w3.org resources

[15:20:58.0000] <caitp->
ulimit maybe? or does that affect osx

[15:22:30.0000] <Domenic>
it affects osx worst of all

[15:22:35.0000] <Domenic>
osx has very low defaults

[15:23:32.0000] <MikeSmith>
ah ok

[15:23:37.0000] <MikeSmith>
what's ulimit?

[15:23:40.0000] <MikeSmith>
/me googles

[15:23:41.0000] <caitp->
kern.maxfiles seems to be around 12k here

[15:28:50.0000] <MikeSmith>
so would the number of open tabs have any effect on this?

[15:29:04.0000] <MikeSmith>
I have about 75 tabs open

[15:30:40.0000] <caitp->
i'm not sure exactly how chromium's socket pooling works, if each frame gets its own socket pool then sure

[15:30:54.0000] <caitp->
running a webserver or database or building big code would add to it

[15:31:12.0000] <caitp->
or maybe it's a bug in chrome, hard to say :<

[15:32:08.0000] <MikeSmith>
wait so I had naively assumed it meant chrome was waiting for a network socket

[15:32:50.0000] <caitp->
psychic debugging is hard, i'm just throwing ideas at you

[15:33:33.0000] <MikeSmith>
heh

[15:34:41.0000] <MikeSmith>
anyway ulimit -n says 2560 on my system, which seems like it should be enough

[15:35:37.0000] <MikeSmith>
I'll give up for now

[15:36:28.0000] <MikeSmith>
on the bright side, it's cool how Chrome doubles as a system load tester

[15:50:10.0000] <jgraham>
They should get bratell on that. I hear his hobby is running at the system resource limits

[15:50:48.0000] <gsnedders>
I seem to remember him claiming to have surprisingly few tabs open when I last spoke to him.

[15:50:53.0000] <gsnedders>
Like only a few hundred.

[15:52:41.0000] <jgraham>
Well with presto on 32bit windows he had enough open to frequently test the OOM handling

[15:59:51.0000] <jgraham>
annevk: Did you see http://daniel.haxx.se/blog/2015/02/24/curl-smiley-urls-and-libc/ ?


2015-02-25
[16:05:05.0000] <MikeSmith>
jgraham: wow when even he can't tell from the specs what's supposed to be allowed, the specs are pretty bad

[16:05:20.0000] <MikeSmith>
Daniel Stenberg I mean

[16:06:48.0000] <jgraham>
Yeah

[16:24:47.0000] <GPHemsley>
/me wonders if "initial MIME type" and "final MIME type" would be clearer than "supplied MIME type" and "sniffed MIME type", respectively.

[16:24:59.0000] <zewt>
cool, another CORS header for everyone to copy and paste blindly into their server

[16:25:08.0000] <zewt>
(heh)

[16:26:35.0000] <TabAtkins>
GPHemsley: initial/final sound good.  supplied/sniffed sound like they're both inputs into an algorithm that'll spit out a final one.

[16:26:46.0000] <TabAtkins>
Or mix 'em up, supplied/final.

[16:26:57.0000] <GPHemsley>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28094

[16:27:04.0000] <GPHemsley>
Could that be what's in play here?

[16:27:49.0000] <TabAtkins>
GPHemsley: Ah, no, in that bug, it's that the phrase "the X is the Y" is unclear - the directionality of the implication isn't obvious.

[16:27:59.0000] <TabAtkins>
I try to be explicit and say "set X to Y"

[16:28:03.0000] <TabAtkins>
Or similar.

[16:28:06.0000] <GPHemsley>
oh, interesting

[16:28:16.0000] <GPHemsley>
leave a comment to that effect?

[16:28:23.0000] <TabAtkins>
Doing so.

[16:28:57.0000] <GPHemsley>
thanks

[16:32:19.0000] <GPHemsley>
TabAtkins: Any insight into the first two quotes?

[16:32:28.0000] <tantek>
why not specified mime type and computed mime type? 1/2 ;)

[16:32:55.0000] <TabAtkins>
No, I don't know about the first two lines. Those seem fine to me.

[16:33:19.0000] <GPHemsley>
tantek: s/specified/supplied/ ?

[16:33:42.0000] <GPHemsley>
I like that

[16:33:47.0000] <GPHemsley>
supplied and computed

[16:33:51.0000] <GPHemsley>
I never liked sniffed

[16:34:12.0000] <tantek>
agreed. use of "sniff" always smelled a bit funny to me.

[16:34:14.0000] <GPHemsley>
/me wonders what has changed out from under him since the last time the spec was updated

[16:34:21.0000] <zewt>
igi smelled

[16:34:29.0000] <GPHemsley>
:P

[16:35:36.0000] <TabAtkins>
 /kick #whatwg tantek Puns too terrible.

[16:37:34.0000] <GPHemsley>
was there some change to the infrastructure, or should I be able to build like I always have?

[16:38:23.0000] <TabAtkins>
You can try it and see?

[16:39:30.0000] <GPHemsley>
I suppose :)

[16:39:42.0000] <GPHemsley>
looks like it should be OK, as long as I don't update anything

[16:54:07.0000] <MikeSmith>
it seems like this "Waiting for available socket" thing in Chrome can't be caused by hitting a system-level limit in OSX, because when it happens with some particular URL, I can open up that same page in Firefox or Safari with no problem

[16:58:35.0000] <GPHemsley>
"X is Y" means "X == Y"

[16:58:46.0000] <GPHemsley>
"set X to Y" means "X = Y"

[16:58:54.0000] <GPHemsley>
/me puts that in the style guide

[17:08:52.0000] <TabAtkins>
GPHemsley: Yeah, that's right.

[17:33:10.0000] <zewt>
MikeSmith: don't know the particular issue, but you could have per-process (maybe per process tree?) limits

[17:37:45.0000] <GPHemsley>
Feedback welcome: https://wiki.whatwg.org/wiki/Specs/style#Equality

[17:37:48.0000] <GPHemsley>
TabAtkins: ^

[17:38:49.0000] <TabAtkins>
Looks good.

[17:39:48.0000] <TabAtkins>
GPHemsley: Do you know the source of the "inverse map" term?

[17:40:04.0000] <TabAtkins>
That's definitely not my expected name for a map where each key can have multiple values.

[17:40:25.0000] <GPHemsley>
TabAtkins: Likely me and/or Wikipedia

[17:40:39.0000] <GPHemsley>
TabAtkins: Feel free to check the logs :P

[17:43:16.0000] <GPHemsley>
nevermind, I'll do it

[17:44:18.0000] <GPHemsley>
6 Nov 2013

[17:44:29.0000] <GPHemsley>
SimonSapin was involved

[17:45:13.0000] <GPHemsley>
http://logs.glob.uno/?c=freenode%23whatwg&s=6+Nov+2013&e=6+Nov+2013&h=inverse+map#c838129

[17:46:23.0000] <TabAtkins>
Okay. ^_^

[17:47:48.0000] <GPHemsley>
yay data!

[17:47:52.0000] <TabAtkins>
Oh wait, I see.  "inverse map" is actually more restrictive than anything in the platform; that really is the correct term in that case.  I was thinking it was basically equivalent to multimap, but it's not.

[17:48:13.0000] <GPHemsley>
:)

[17:50:32.0000] <GPHemsley>
[ For a keyed collection of values, use "inverse map" when there can be more than one value per key and only one key per value  ]

[17:53:14.0000] <GPHemsley>
hmm... I suppose that means that, if there are no orphans, the number of values is always greater than or equal to the number of keys

[17:53:26.0000] <GPHemsley>
/me wanders off

[17:55:47.0000] <GPHemsley>
/me returns briefly to alert Hixie to the terminology change in mimesniff

[17:56:03.0000] <Hixie>
file a bug

[17:56:04.0000] <Hixie>
:-)

[17:58:21.0000] <MikeSmith>
zewt: ah ok

[19:12:35.0000] <MikeSmith>
Hixie: have you got any ideas on how we want to deal with document conformance for documents that contain custom elements

[19:13:00.0000] <MikeSmith>
I mean both spec-wise and for conformance checkers

[19:13:53.0000] <MikeSmith>
as far as the validator we could of course trivially just make it ignore any element names that contain hyphens

[19:15:10.0000] <MikeSmith>
but the downside of that is we'd lose the ability to help people catch cases where they mistyped an element name by putting a stray hyphen into it

[19:15:23.0000] <MikeSmith>
though I think that's probably a very rare mistake to make

[19:15:52.0000] <MikeSmith>
and if they did that for a non-void element, they'd have to make that same mistake twice

[19:16:44.0000] <MikeSmith>
because otherwise the validator would at least emit an error about finding an end tag for an element that's not open

[19:19:31.0000] <MikeSmith>
but the bigger downside is that trivally ignoring any element with a hyphen in its name would also mean any of its child elements also get ignored by the validator

[19:23:16.0000] <Domenic>
My suggestion: Output a list of hyphen-containing elements, highlight somehow any that differ by one or two characters, especially if one of the different-by-one's only occurs once or twice.

[19:26:11.0000] <MikeSmith>
Domenic: OK yeah that would help

[19:27:46.0000] <MikeSmith>
but we still would have the problem that the validator can't do any checking of the child content of a custom element without knowing or assuming what type of content the element's meant to have

[19:28:42.0000] <MikeSmith>
I guess one way to deal with that could be to just try any child element as a div as a far as validation of its child content goes

[19:29:19.0000] <MikeSmith>
but then some custome elements might be meant for use inline, as phrasing content

[19:31:36.0000] <Domenic>
Hmm yeah seems not possible to solve without external metadata

[19:32:13.0000] <Domenic>
Which would require custom element authors to be people who want to give thought to validation constraints :/

[19:34:36.0000] <MikeSmith>
yup

[19:34:43.0000] <MikeSmith>
which isn't practical

[19:36:03.0000] <MikeSmith>
but short of external metadata I could have the validator try to heuristically determine what kind of content the custom element is

[19:37:05.0000] <MikeSmith>
e.g., a simple case is, if the custom element is itself a descendant of an element that can only contain phrasing content

[19:37:12.0000] <MikeSmith>
e.g., a <p> element

[19:37:39.0000] <MikeSmith>
then in that case we can assume that the custom element can also only contain phrasing content

[19:38:10.0000] <MikeSmith>
and implementation-wise I could just have the validator treat it the same as a <span> I guess

[19:38:46.0000] <MikeSmith>
in other words, we just make the content model of all custom elements be "transparent"

[19:39:06.0000] <Hixie>
fundamentally, no, i have no idea.

[19:39:19.0000] <Hixie>
i mean that's what DTDs were to SGML

[19:39:22.0000] <Hixie>
and that failed

[20:04:08.0000] <Domenic>
You could imagine a "custom elements validator config"

[20:04:21.0000] <Domenic>
It could be very simple, starting with one line or so for each element

[20:04:28.0000] <Domenic>
And could become sharable

[20:04:42.0000] <Domenic>
Or people could end up just inputting it into a textbox alongside their HTML content

[20:04:49.0000] <Domenic>
and maintaining it in a .txt file they use

[20:05:10.0000] <Hixie>
this isn't new technology. xml schemas, dtds, relaxng, they're all elaborate ways to do this

[20:05:21.0000] <Hixie>
and they all basically uniformally fail in a web enviroment

[20:05:21.0000] <MikeSmith>
Domenic: right, something like that may be what we end up needing in the long run

[20:05:50.0000] <Hixie>
i mean this really is exactly what we're doing here. we're making in possible for people to use a meta language to make a new vocabulary

[20:05:59.0000] <Hixie>
this is exactly what sgml was, and xml later.

[20:06:26.0000] <MikeSmith>
Hixie: I'm not sure you're completely right about those existing schema languages having ways to do this

[20:06:34.0000] <MikeSmith>
certainly Relaxg

[20:06:56.0000] <Hixie>
i don't mean specifically define a vocabulary for custom elements in html

[20:07:17.0000] <Hixie>
i mean the class of problems of "describe validation criteria for a vocabulary in a metalanguage"

[20:07:29.0000] <MikeSmith>
ok

[20:08:18.0000] <MikeSmith>
well I think the problem with most existing schema approaches for validation is that they're all grammar-based

[20:08:36.0000] <MikeSmith>
so they by default say nothing is allowed anywhere

[20:08:47.0000] <MikeSmith>
it's like Deny: *

[20:09:23.0000] <MikeSmith>
and they all require you to them explicitly define what's allowed where

[20:10:25.0000] <MikeSmith>
the other approaches like schematron that are assertion-based do the opposite Allow:* way of saying everything's allowed everywhere

[20:11:02.0000] <Domenic>
I think my approach is predicated on my guess that those approaches failed because of usabilty issues

[20:11:18.0000] <MikeSmith>
anyway for better or worse the validator at its core is a grammar-based checker so we're stuck with that limitation until we come up with something better to replace it

[20:11:35.0000] <Hixie>
i think these approaches failed because most people don't care to define constraints for their vocabularies.

[20:11:41.0000] <MikeSmith>
bingo

[20:11:56.0000] <MikeSmith>
in the past very few people had any need to

[20:12:06.0000] <Domenic>
Whereas something like "contains only: phrasing content" or "contains only: [x-menuitem]" --- with nothing else --- might succeed, at least in the domain of people who care enough about validation to lug around the metadata

[20:12:09.0000] <MikeSmith>
but I think custom elements changes that

[20:13:16.0000] <MikeSmith>
Domenic: yeah I think what you've described would need to be limited to some very simple limited easy to grok expression language

[22:44:45.0000] <annevk>
jgraham: left a reply, URL Standard has all the answers, but when you start looking at RFCs... yeah

[02:23:54.0000] <annevk>
JakeA: DOM === (!JavaScript && !<canvas>)

[02:24:15.0000] <JakeA>
annevk: haha, perfect!

[02:25:34.0000] <Ms2ger>
I'm having issues with my HTML5 DOM HTTP

[04:32:02.0000] <jgraham>
annevk: Do we know how common xml:base is?

[04:51:53.0000] <annevk>
jgraham: foolip has been counting it I think

[04:52:05.0000] <annevk>
philipj that is, these days

[04:52:43.0000] <jgraham>
Oh, he changed nicks

[04:53:36.0000] <jgraham>
(thinking about it more, I don't really care that much for the problem I had in mind)

[04:53:43.0000] <jgraham>
(so don't worry)

[04:55:36.0000] <GPHemsley>
Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28100

[04:56:27.0000] <annevk>
jgraham: see https://code.google.com/p/chromium/issues/detail?id=341854 for progress on removing xml:base

[04:57:19.0000] <annevk>
jgraham: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 is still awaiting a volunteer

[05:30:14.0000] <hemanth>
How do I import a reserved/key word? Something like import { 'return' } as identity from 'fj-maybe'; does not work...

[05:31:17.0000] <hemanth>
fj-maybe does: export default { 'return' (value) {return value;} }

[05:49:32.0000] <philipj>
annevk, jgraham, it's more convenient to be philipj in #blink, so...

[05:50:30.0000] <philipj>
so the xml:base counter isn't for the presence of the attribute but just when it has an observable effect in Blink

[05:50:51.0000] <philipj>
https://www.chromestatus.com/metrics/feature/timeline/popularity/580

[05:51:25.0000] <philipj>
https://www.chromestatus.com/metrics/feature/timeline/popularity/681 is for the reflected attribute in SVG

[05:52:02.0000] <annevk>
looks great

[05:52:22.0000] <annevk>
but it also seems that in Chrome it has barely any effect at all

[05:52:32.0000] <annevk>
that's not true for Gecko though since no other browser does it...

[05:53:11.0000] <philipj>
annevk: note that the SVG counter (681) hasn't reached stable yet, but I'm quite optimistic

[05:53:40.0000] <jgraham>
philipj: On an entirely different topic, I needinfo'd you on a bug about wpt media test source selection. I hope you don't mind

[05:54:02.0000] <philipj>
jgraham: yep, I saw that, and don't mind :)

[05:54:41.0000] <philipj>
I also have a philipj⊙oc account in your Bugzilla, not sure why I have two

[05:55:10.0000] <jgraham>
Ah, foolip is a more unique search string ;)

[05:58:11.0000] <philipj>
yes it is :)

[06:03:46.0000] <philipj>
jgraham: I've replied to your needsinfo bug

[06:03:57.0000] <jgraham>
philipj: Thanks!

[06:03:58.0000] <philipj>
I like this needsinfo system BTW

[06:04:37.0000] <Ms2ger>
MikeSmith bugged systeam about that, I wonder what happened

[06:04:42.0000] <jgraham>
Yeah, it seems to work quite well

[06:05:02.0000] <Ms2ger>
philipj, you can get accounts merged, fwiw... You need to file a bug somewhere

[06:05:53.0000] <MikeSmith>
I got a reply on the needsinfo thing—basically a "maybe"—so at least they didn't reject it yet

[06:06:07.0000] <MikeSmith>
I need to get back to them and continue to lobby for it

[06:32:10.0000] <Ms2ger>
MikeSmith, any chance you can get a big banner on http://www.w3.org/TR/Window/?

[06:32:56.0000] <MikeSmith>
Ms2ger: yeah

[06:33:08.0000] <MikeSmith>
got a page I can copy the banner from?

[07:02:38.0000] <Ms2ger>
MikeSmith, http://www.w3.org/TR/CSS1/ maybe

[07:05:32.0000] <MikeSmith>
/me looks

[07:06:19.0000] <Ms2ger>
MikeSmith, or redirect to html.s.w.o ;)

[07:11:01.0000] <MikeSmith>
Ms2ger: would that I could 😄

[07:11:57.0000] <Ms2ger>
MikeSmith, or, hell, the fork

[07:23:32.0000] <philipj>
Ms2ger: will a bug just anywhere do the trick? ;)

[07:25:31.0000] <Ms2ger>
<glob> Ms2ger, bugzilla.mozilla.org :: administration

[07:25:31.0000] <Ms2ger>
<glob> Ms2ger, we'll need a comment from both accounts

[07:42:20.0000] <MikeSmith>
Ms2ger: done

[07:43:20.0000] <Ms2ger>
MikeSmith, yay, advanced 8 years :)

[07:43:45.0000] <MikeSmith>
hahah

[08:19:01.0000] <annevk>
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0414.html :-(

[08:20:07.0000] <annevk>
I don't even know where to start if I wanted to reply to that

[08:56:12.0000] <Domenic>
Yeah :(

[08:56:17.0000] <Domenic>
we talked about this at TAG f2f

[08:56:30.0000] <Domenic>
linked data software apparently isn't aware of redirects or canonicalization or anything like it

[08:56:35.0000] <Domenic>
just uses URLs as long guids

[09:00:10.0000] <annevk>
That doesn't seem problematic

[09:00:30.0000] <annevk>
They should just have additional logic for fetching resources if they actually plan on doing that

[09:01:23.0000] <annevk>
Also, there's owl:sameAs... They just need to invest some work in integrity and such

[09:01:24.0000] <Domenic>
agreed

[09:03:01.0000] <annevk>
Does anyone know what other browsers call what Gecko calls "load group"? The thing that's sort of responsible for keeping track of all fetches within an environment?

[09:24:08.0000] <jamesr___>
what's an "environment"?

[09:24:29.0000] <jamesr___>
a tab?

[09:38:35.0000] <annevk>
jamesr___: window or worker

[09:38:50.0000] <annevk>
jamesr___: anything with a global object

[10:51:54.0000] <jsbell>
Offhand, anyone know why the WebSocket constructor uses DOMString[] instead of sequence<DOMString> ?

[11:00:03.0000] <jgraham>
jsbell: No, but I wonder if you know anything about the server configuration for the blink service worker tests :)

[11:00:25.0000] <jsbell>
jgraham: not as much as I wish I knew, but I can try and get answers for you

[11:02:14.0000] <jgraham>
jsbell: I'm trying to work out what to map the various servers to e.g. 127.0.0.1:8000, etc. It wasn't immediately clear (without trying too hard) what relationship each was intended to have with the main server (different post, different host, etc.)

[11:04:26.0000] <jsbell>
jgraham: ah yes.... "intended" will be difficult w/o context. Generally it's just to get different origins, and it may be author's whim whether to vary host or port. Let me quick skim any docs we have to see if there's guidance...

[11:04:45.0000] <jgraham>
Oh dammit these tests have changed since I forked them :(

[11:07:11.0000] <jsbell>
jgraham: http://www.chromium.org/developers/testing/webkit-layout-tests#TOC-Tests-that-use-a-HTTP-Server says more... but I had never even heard of "pending tests" until now, digging...

[11:07:21.0000] <jgraham>
It would be nice to coordinate with the people actually writing the tests here. I guess I could just email them…

[11:08:14.0000] <jsbell>
jgraham: service workers specifically, right?

[11:08:23.0000] <jgraham>
jsbell: Yeah

[11:08:35.0000] <jgraham>
jsbell: That page is helful, thanks

[11:08:40.0000] <jgraham>
*helpful

[11:14:01.0000] <jsbell>
jgraham: I'm pinging the GOOG SW folks to see what the best way to coordinate with you would be. We've got some tracking cr bugs, we could spin up an issue on the SW github, etc.

[11:19:28.0000] <jsbell>
jgraham: so far as I can tell by looking at our apache config, that page is a lie; we use 8000, 8080, and 8443, not the other ports.

[11:25:48.0000] <jgraham>
jsbell: Awesome, thanks!

[11:26:05.0000] <jgraham>
annevk: What's the easiest way to tell if a string a an absolute url?

[11:26:54.0000] <jsbell>
jgraham: and from a random sampling, it appears to just be up to the test author to chose between varying host or port to get a different origin. Apart from security/origin tests, which try both, of course.

[11:44:53.0000] <wanderview>
JakeA: can we go ahead and remove scriptCaches

[11:44:55.0000] <wanderview>
?

[11:48:28.0000] <wanderview>
having a writable Cache that under-pins the ServiceWorker seems a bit dangerous... and we have no method to mark a Cache object read only currently

[11:49:04.0000] <wanderview>
I'm asking baku not to expose scriptCache in gecko for now

[11:55:08.0000] <jsbell>
wanderview: no plans to implement it any time soon in blink, either

[11:55:36.0000] <wanderview>
thanks... good to know

[11:58:03.0000] <wanderview>
jsbell: updated https://github.com/slightlyoff/ServiceWorker/issues/473

[13:18:11.0000] <jamesr___>
annevk: there's the thing that drives the spinner, which may be similar

[13:43:48.0000] <jsbell>
jgraham: also http://www.chromium.org/blink/serviceworker/testing - apart from host/port config and the py/php thing, if there's anything we're doing "weird" in our tests that's going to make upstreaming them more difficult, let me know and we can fix that doc and update our tests.

[13:49:03.0000] <jgraham>
jsbell: Thanks!


2015-02-26
[22:32:07.0000] <annevk>
jgraham: parse it and see if the serialized result is the same as the input

[22:32:39.0000] <annevk>
jamesr___: ah, but what it's called?

[22:43:13.0000] <karlcow>
https://bugzilla.mozilla.org/show_bug.cgi?id=1137079

[22:43:22.0000] <karlcow>
Bug 1137079 - https://whatwg.org/ Secure Connection Failed (Error code: ssl_error_no_cypher_overlap)

[23:25:47.0000] <annevk>
karlcow: can you reproduce it?

[23:31:11.0000] <karlcow>
/me is switching to Firefox 39.0a1 (2015-02-25)

[23:31:21.0000] <karlcow>
/me is going to https://bugzilla.mozilla.org/show_bug.cgi?id=1137079

[23:33:52.0000] <karlcow>
failing on https://forums.whatwg.org/

[23:34:25.0000] <annevk>
karlcow: yeah, multiple subdomains are not on the whitelist, I left a comment on the whitelist bug emk pointed out

[23:34:29.0000] <karlcow>
/me sees https://hg.mozilla.org/releases/mozilla-aurora/file/2e3aaa26bca4/security/manager/ssl/src/IntolerantFallbackList.inc

[23:34:36.0000] <annevk>
karlcow: euh, emk did point that out, someone else did

[23:34:55.0000] <annevk>
karlcow: e.g. images.w.o spec.w.o validator.w.o all fail too

[23:35:12.0000] <karlcow>
ah yes.

[23:35:12.0000] <karlcow>
https://bugzilla.mozilla.org/show_bug.cgi?id=1137079#c6

[23:35:36.0000] <karlcow>
/me hopes the whitelist is serverside and not included in the client.

[23:37:01.0000] <annevk>
karlcow: it's included in the client

[23:37:26.0000] <annevk>
karlcow: not sure why it matters

[23:40:22.0000] <karlcow>
annevk: for updates.

[23:40:41.0000] <karlcow>
When it's included in the client you create a delay

[23:41:02.0000] <karlcow>
it's becoming an acute issue when it's on Mobile.

[23:41:22.0000] <karlcow>
because not all operators decide to update the OS.

[23:41:28.0000] <karlcow>
(for FIrefox OS)

[23:41:41.0000] <karlcow>
so you keep having a whitelist which is not accurate anymore.

[23:41:53.0000] <karlcow>
And domains get bought by other people, etc.

[23:42:54.0000] <karlcow>
We had the issue for UA override on Firefox OS 1.0.

[23:43:16.0000] <karlcow>
So we decided to switch to server-side for the next version.

[23:44:02.0000] <karlcow>
So we could remove (or add) at will a UA override without having to wait for the operator to cherry pick the update, or waiting that it will never update. :)

[23:48:16.0000] <annevk>
That depends on what the update logic is. If operators decide to remove the update logic...

[00:35:05.0000] <JakeA>
wanderview: yeah, kill it

[00:53:00.0000] <JakeA>
wanderview: I've removed it from the spec. I forgot it was still there. I think there are uses, but we'll properly think it through before adding it back

[01:08:00.0000] <zcorpan>
Hixie: looks like there are a few markup errors in your source that darobin fixed in https://github.com/w3c/spork/commits/master (like x-data)

[01:39:58.0000] <JakeA>
"Release the storage mutex!" is my favourite thing to shout in an evil voice

[02:07:46.0000] <annevk>
JakeA: why is default() still in the spec?

[02:08:12.0000] <annevk>
JakeA: also, nobody implements the storage mutex :-(

[02:08:37.0000] <JakeA>
annevk: I'm working through issues now. Will get to that one :)

[02:08:44.0000] <annevk>
JakeA++

[02:09:07.0000] <annevk>
(I like to think that gives you extra speed.)

[02:12:02.0000] <JakeA>
:D

[03:58:09.0000] <JakeA>
annevk: https://github.com/slightlyoff/ServiceWorker/issues/631#issuecomment-75740946 are you saying the client may have gone before the beacon initiates its request?

[04:15:31.0000] <JakeA>
annevk: So, without event.default(), how would I fetch a resource (say, CSS) in a way that makes relative urls in the CSS relative to finalURL

[04:15:33.0000] <JakeA>
?

[05:33:24.0000] <annevk>
JakeA: yes, the client may have gone

[05:34:04.0000] <annevk>
JakeA: ping="" and such are required to be done at some point, but usually after the user has navigated away, the whole point is that they're a replacement for synchronous beforeunload tricks

[05:34:19.0000] <annevk>
JakeA: might still not be a problem I suppose, depends a bit on the definitions

[05:34:27.0000] <JakeA>
annevk: that's a good case for it being clientless, or perhaps even not using the SW at all

[05:34:49.0000] <annevk>
JakeA: I think it should use the SW just like it should be subject to CSP, we don't really want special cases

[05:35:22.0000] <JakeA>
that's fair, as long as they don't hold up a waiting SW promoting to active

[05:35:28.0000] <annevk>
JakeA: people are going to want to be able to catch all networking activity

[05:35:29.0000] <JakeA>
but I think that's fine

[05:35:46.0000] <annevk>
JakeA: https://fetch.spec.whatwg.org/#dom-response-finalurl was the answer we designed together for base URLs

[05:37:20.0000] <JakeA>
annevk: if I use fetch('/static/fallback.html') as a response to a navigation, does it effect base urls or the url bar?

[05:39:19.0000] <annevk>
JakeA: not unless you set finalURL

[05:40:06.0000] <annevk>
JakeA: I'm not sure we fully considered the case of contexts that set the manual redirect flag though... Hmm

[05:40:42.0000] <JakeA>
annevk: ahhh ok, so it's not automatically set. So fetch('/blah.css') will swallow redirects by default, if I want the base url to reflect that I have to set finalURL manually (but, I can't observe the redirects)

[05:41:03.0000] <annevk>
JakeA: yes

[05:42:43.0000] <annevk>
JakeA: for navigation and other contexts that don't follow redirects finalURL should probably be either be ignored or be cause for a network error or a really special synthetic redirect that I'm sure of how it would work

[05:43:23.0000] <JakeA>
ignore seems good

[05:43:52.0000] <JakeA>
annevk: So if I wanted to fetch(someCSS) & have potential redirects reflected in the base url, is there a way to do that?

[05:46:04.0000] <annevk>
JakeA: yeah, but it's cumbersome I see now

[05:46:20.0000] <annevk>
JakeA: once you get hold of res, you'd do res.finalURL = true

[05:46:34.0000] <JakeA>
ohhhhhhhhh, it's a boolean!

[05:46:39.0000] <JakeA>
That was the missing bit

[05:46:45.0000] <JakeA>
nah, that's not cumbersome that's fine

[05:46:57.0000] <annevk>
JakeA: but it seems like you want something like fetch(someCSS, {finalURL:true }) maybe... hmm

[05:47:01.0000] <annevk>
ok

[05:47:10.0000] <annevk>
It feels a bit better to expose it only on response

[05:47:34.0000] <JakeA>
fetch(url).then(r => r.finalURL = true && r)

[05:47:48.0000] <JakeA>
fetch(url).then(r => (r.finalURL = true) && r)

[05:49:51.0000] <JakeA>
annevk: Willing to bikeshed on the name? I totally assumed finalURL would be a string url

[05:51:12.0000] <annevk>
JakeA: yeah, though I would prefer a ticket someplace then

[05:55:30.0000] <JakeA>
annevk: https://github.com/slightlyoff/ServiceWorker/issues/607#issuecomment-76181254

[05:57:57.0000] <annevk>
JakeA: yeah that seems good, and yeah, it's supposed to be stored as part of transfering the response

[05:58:10.0000] <annevk>
JakeA: otherwise it wouldn't make it into the Fetch process either

[06:02:02.0000] <annevk>
"Intent to Remove showModalDialog" exciting day

[06:18:01.0000] <annevk>
JakeA: renamed finalURL btw

[06:18:35.0000] <JakeA>
\o/

[06:18:42.0000] <JakeA>
Lemmie remove event.default()

[06:18:46.0000] <JakeA>
I'm going to enjoy this

[06:36:02.0000] <r4vi>
is there any proposals for a 'force incognito' API

[06:36:14.0000] <r4vi>
for sites that say domestic abuse victims

[06:36:18.0000] <r4vi>
or something would use

[06:42:05.0000] <JakeA>
It'd be nice if a browser could take a tab incognito. Undoing history should be ok, tougher to deal with cookie/idb/ls changes

[06:43:19.0000] <zcorpan>
JakeA: try opera 12

[06:43:31.0000] <JakeA>
zcorpan: did it do that?

[06:43:38.0000] <JakeA>
those guys thought of everything

[06:43:41.0000] <zcorpan>
yes

[06:44:14.0000] <jgraham>
"Opera did it first"

[06:44:38.0000] <zcorpan>
well you could open a new private tab, you couldn't make an existing tab private

[06:45:06.0000] <JakeA>
oh, I meant taking an existing tab private

[06:45:13.0000] <JakeA>
*everyone* can open private tabs

[06:45:57.0000] <zcorpan>
um... how?

[06:46:29.0000] <JakeA>
incognito… or are you going to be pedantic and say that's a new window not tab? :P

[06:46:49.0000] <zcorpan>
yes? of course a window is not a tab :-)

[06:46:56.0000] <JakeA>
*fert*

[06:47:09.0000] <JakeA>
that's a fart sound for your pedantry

[06:48:14.0000] <zcorpan>
ah ok, i never knew it was pedantry that came out of my ass :-D

[06:49:05.0000] <JakeA>
But the idea of a forcing incognito is interesting. It'd need to be done as a header. I imagine banks would all do it for "security" reasons, so the user would need a way to opt out, and if that opt out is "remembered" you kinda lose the original use-case

[06:49:14.0000] <zcorpan>
so going back, what would you expect to happen when you make an existing tab private?

[06:50:03.0000] <JakeA>
zcorpan: it to "undo" any non-private stuff it did, and reload in private mode. I realise the undo part is not really possible

[06:51:34.0000] <JakeA>
r4vi: is this just a sudden idea or is a group lobbying for this?

[06:53:02.0000] <r4vi>
JakeA: I'm actually working on a site that would find this useful

[06:53:07.0000] <r4vi>
so sudden idea

[06:53:09.0000] <jgraham>
It should be noted that it doesn't offer any "meaningful" security e.g. someone could set up the router to log all outbound DNS

[06:53:35.0000] <JakeA>
that's true. Could even be false security.

[06:53:51.0000] <jgraham>
Of course the population of people who would do that is smaller than the population of people that can look through browser history

[06:54:08.0000] <r4vi>
JakeA: we're currently linking them to this guide http://www.youandco.org.uk/node/240

[06:54:22.0000] <r4vi>
but wish there was a more user-friendly way

[09:19:39.0000] <Ms2ger>
:( https://bugzilla.mozilla.org/show_bug.cgi?id=1107378

[09:29:16.0000] <jgraham>
Not that surprising

[10:09:33.0000] <Ms2ger>
So who supports before/afterscriptexecute now? Gecko/Servo/Presto?

[10:27:37.0000] <wanderview>
JakeA: if a ServiceWorker script does "new Worker('nested_worker.js')"... is that something we support? should the nested worker script be automatically cached like importScript()?

[11:11:18.0000] <JakeA>
wanderview: I don't see why we wouldn't support it, but I don't think it should be importScript cached.

[11:11:59.0000] <JakeA>
But it wouldn't be a lot of use

[11:12:56.0000] <JakeA>
But if devs find a use for it, they can store the script text in idb or a cache

[11:28:37.0000] <wanderview>
JakeA: I think we're going to disallow it for now in gecko... another problem is life cycle... if the SW gets killed at any time... it should stop the dedicated worker... (right?)  seems like it will be very difficult to use

[11:28:52.0000] <wanderview>
JakeA: if they store the script text manually... then they are using a data URI worker, right?

[11:29:49.0000] <wanderview>
it was my impressions blink didn't support nested workers at all yet, anyway... so this may just be a gecko thing

[11:41:16.0000] <JakeA>
wanderview: yeah, and yeah it'll get killed when the SW does. I can't think of many use cases for wanting a dedicated worker in a SW.

[11:41:36.0000] <wanderview>
JakeA: the nested SharedWorker, though... that could be useful

[11:42:19.0000] <JakeA>
wanderview: an interesting question I guess is whether the request for the worker/sharedworker goes through the SW

[11:43:05.0000] <wanderview>
JakeA: if it originates from a ServiceWorker, I thought the skip serviceworker flag was set

[11:46:12.0000] <wanderview>
JakeA: so if the sharedworker was first created from the document... then intercepted by SW... if first created from SW, then no interception... so dead simple for devs!

[11:46:28.0000] <wanderview>
^so dead simple^sounds dead simple

[11:46:51.0000] <wanderview>
of course no one supports this case currently as far I know

[11:46:59.0000] <wanderview>
we only expose SharedWorker on the main thread

[12:36:51.0000] <Ms2ger>
longdesc is a rec

[12:36:56.0000] <Ms2ger>
Good job everyone

[12:37:06.0000] <Ms2ger>
Can we now finally go back to something useful?

[12:44:41.0000] <smaug____>
like reviewing perf wg's specs? Sounds like a good idea

[12:44:55.0000] <smaug____>
/me hears Ms2ger just volunteered

[12:45:21.0000] <Ms2ger>
I was thinking more shutting them down on the next rechartering

[12:45:36.0000] <jamesr___>
sgtm

[12:45:59.0000] <jamesr___>
like most things in w3c it was created to work around other badness in w3c process

[12:46:13.0000] <jamesr___>
now that all vendors have official joined the WG there's no point in having it be separate

[12:46:42.0000] <jamesr___>
(before they joined there was the possibility of moving things through that WG faster than others like public-webapps due to membership differences)

[12:46:51.0000] <smaug____>
(perf wg's issues aren't w3c process issues)

[12:47:03.0000] <smaug____>
/me goes back to reviewing

[12:47:05.0000] <Ms2ger>
Perf wg is more "eh, whatever"

[12:47:25.0000] <Ms2ger>
"You got comments? Ain't nobody got time for that!"

[12:55:43.0000] <TabAtkins>
Ms2ger: "But we can measure exactly how much time ain't nobody got!"

[12:58:24.0000] <miketaylr>
can't wait for longdesc2

[13:21:14.0000] <jamesr___>
smaug____: i'm just talking about why it was created and used, not how it functions in practice

[13:21:28.0000] <jamesr___>
i agree it's pretty terrible

[13:30:32.0000] <smaug____>
ah, I don't even recall why it was created (and why the specs aren't written in webapps wg)

[13:45:27.0000] <jamesr___>
concerns about charter or velocity or both in the webapps wg

[13:46:02.0000] <jamesr___>
in w3c if you make a new wg you get to pick the members and charter and you can pick a set of members that will agree to the charter you want

[13:46:24.0000] <jamesr___>
whereas to spec a new thing in an existing WG you have to make sure it's within charter and if not get all existing members of the WG to agree to that charter

[13:46:25.0000] <Ms2ger>
In whatwg, you can write a spec :)

[13:51:58.0000] <caitp->
who is going to stop you from writing a spec

[13:52:07.0000] <caitp->
the tzar of the internet?

[14:12:25.0000] <jamesr___>
if you want to publish it as a w3c spec (which some people find important, not that i find all that much value in that personally) then the w3c will

[14:13:13.0000] <Ms2ger>
Sure, every monkey can get a spec published at w3c

[14:13:16.0000] <Ms2ger>
Case in point: me

[14:14:48.0000] <TabAtkins>
Ms2ger: Wait, which spec did you write?

[14:15:26.0000] <Ms2ger>
DOM

[14:15:32.0000] <Ms2ger>
Under various names

[14:15:33.0000] <wanderview>
jsbell: hi!  do you know about how blink offlines the ServiceWorker script itself and its importScript() scripts?

[14:16:24.0000] <wanderview>
jsbell: just curious how blink handles a delayed importScript() call...  like if the script does setTimeout(function() { importScript('annoying.js'); }, 5000)

[14:17:09.0000] <wanderview>
I guess we just don't guarantee that any delayed script loads will be cached?

[14:17:25.0000] <wanderview>
just makes it difficult to ensure we have a coherent set of scripts cached for offline use

[14:17:52.0000] <TabAtkins>
wanderview: ServiceWorkers that last too long just get killed; nothing gets preserved across.

[14:18:19.0000] <TabAtkins>
If you want to cache scripts with better guarantees, do a standard fetch and put it in a cache, then import it.

[14:19:41.0000] <wanderview>
TabAtkins: with importScript(datauri) or something?  I wasn't clear how someone could take a fetch Response and get it into importScript()

[14:19:57.0000] <TabAtkins>
Given the current API, yeah, a data: url.

[14:21:00.0000] <wanderview>
TabAtkins: so you think this is a dev evangelism issue?  people should just use importScripts() synchronously with the top line SW script or not at all?

[14:21:11.0000] <TabAtkins>
I suspect so, yeah.

[14:21:38.0000] <TabAtkins>
Standard SW wisdom: don't count on anything sticking around, you'll be disappointed eventually.

[14:22:17.0000] <wanderview>
TabAtkins: yea... I know... but as an implementer, I'd like to be able to say "we've successfully offlined this SW and its dependent scripts"... but basically we can't ever know when its done

[14:22:53.0000] <TabAtkins>
Well, yeah, you have no idea when a SW is going to request more things off the network.

[14:24:26.0000] <wanderview>
I guess thats why this is still open:  https://github.com/slightlyoff/ServiceWorker/issues/106

[14:25:47.0000] <slightlyoff>
hrm, I'm not sure that still needs to be open

[14:26:12.0000] <slightlyoff>
TabAtkins: also, that's pretty BS

[14:26:21.0000] <Ms2ger>
Bikeshed?

[14:26:26.0000] <TabAtkins>
slightlyoff: ?

[14:26:39.0000] <slightlyoff>
TabAtkins: "requesting more things off the network" post-install-setup phase means you didn't really want 'em

[14:26:51.0000] <slightlyoff>
TabAtkins: if you liked it, you should have put a top-level importScripts() on it

[14:27:11.0000] <TabAtkins>
Um, okay. I mean, sure, it's obviously not a *strict dependency*, but I fail to see the relevance.

[14:27:43.0000] <wanderview>
slightlyoff: its unclear to me from #106 what the end result of this was...

[14:28:07.0000] <wanderview>
and searching the spec for importScript does not reveal anything

[14:28:25.0000] <slightlyoff>
/me looks

[14:28:34.0000] <slightlyoff>
yeah, I'm not sure we spec'd it, so having it open does seem right

[14:28:36.0000] <wanderview>
sorry if its obvious and I missed it

[14:29:14.0000] <wanderview>
it sounds like its just a best effort caching... when the ServiceWorker script loads something through importScript()... put it in the cache

[14:29:16.0000] <slightlyoff>
or behavior (Blink) is to cache resources requested at initial download time (via importScripts) alongside the SW script version

[14:29:35.0000] <slightlyoff>
and the dependencies are only updated when the SW script updates

[14:29:40.0000] <wanderview>
slightlyoff: for delayed importScripts... it does not cache?

[14:29:47.0000] <slightlyoff>
(e.g., you run through an upgrade)

[14:29:47.0000] <wanderview>
or thats just best effort

[14:29:53.0000] <slightlyoff>
wanderview: I don't think we cache.

[14:30:01.0000] <wanderview>
hmm

[14:30:07.0000] <slightlyoff>
wanderview: at least not more than the HTTP cache provides

[14:30:19.0000] <slightlyoff>
wanderview: and that's the intended behavior

[14:30:51.0000] <slightlyoff>
wanderview: you can do more eval()-ing cache'd content if you want to

[14:31:12.0000] <slightlyoff>
wanderview: but that's all very explicit, which is what we were going for in the design

[14:31:21.0000] <wanderview>
slightlyoff: in gecko, I'm not sure we have an easy way to tell the difference between top level importScripts() and delayed importScripts()

[14:31:49.0000] <slightlyoff>
you don't have some marker for the SW script that you're caching?

[14:32:10.0000] <slightlyoff>
i.e., do you have a way of storing the SW script that opts it out of HTTP cache eviction?

[14:32:46.0000] <slightlyoff>
I don't know it's a problem to cache other importScripts more aggressively

[14:32:47.0000] <wanderview>
slightlyoff: we definitely know which one is the SW script

[14:33:03.0000] <slightlyoff>
but I think we want to keep devs from depending on that

[14:33:21.0000] <wanderview>
I'm not 100% sure... but I think the importScripts all just come out of the js engine as "something called importScripts!"... we don't know which parent script called it

[14:33:33.0000] <slightlyoff>
otherwise it becomes nearly impossible to reason about what's going to work in your SW as a download error in an importScript can screw you entirely

[14:33:44.0000] <wanderview>
/me traces more code.

[14:34:02.0000] <slightlyoff>
how do you keep them with the same durability as the SW script? That's the only invariant we NEED to preserve

[14:34:30.0000] <wanderview>
slightlyoff: we are internally using the Cache API

[14:34:37.0000] <slightlyoff>
would be fatal to a site if it importscripts started failing but the main SW script were there

[14:34:51.0000] <slightlyoff>
wanderview: seems legit. Don't think you've got a problem here then.

[14:34:57.0000] <wanderview>
slightlyoff: right... we are keeping the importScripts as persistent as the SW script...

[14:35:04.0000] <wanderview>
slightlyoff: its just we may over-cache compared to blink

[14:35:09.0000] <wanderview>
for delayed importScripts

[14:35:43.0000] <wanderview>
its a subtle compatibility difference... hopefully it doesn't bite too many people

[14:36:06.0000] <slightlyoff>
I think that's fine; contra TabAtkins, we're going to understand install-time vs. post-install-time requests for imported scripts

[14:36:12.0000] <wanderview>
I guess the http cache being there also muddies the water... people may think its fully offlined, but its just an aging http cache

[14:36:20.0000] <slightlyoff>
TabAtkins: I don't think this is really that bad, though...do you?

[14:36:50.0000] <slightlyoff>
wanderview: I think our long-term solution will be devtools warnings about dynamic importScripts() calls

[14:37:01.0000] <TabAtkins>
I'm pretty sure everything you said agrees with what I said, so no, I don't think it's bad. ^_^

[14:37:12.0000] <slightlyoff>
TabAtkins: ah, right, then I misunderstood you. Sorry!

[14:37:14.0000] <wanderview>
thanks for the help

[14:37:31.0000] <TabAtkins>
(I said that dynamic/delayed importScript() calls should instead be fetch()/cache, then import them when you're sure they've arrived.)

[14:38:10.0000] <slightlyoff>
TabAtkins: yeah, that's totally true

[14:38:49.0000] <slightlyoff>
will ping jungkees about getting this squred away. I think we only need to say that importScripts post-initial-download MAY be discarded by the UA

[14:39:26.0000] <slightlyoff>
wanderview: using the Cache API should prevent the real compat worry (in my mind), which is the scripts getting updated at different rates by UAs

[14:43:34.0000] <wanderview>
slightlyoff: I've been corrected by baku and nsm... we do have a way to implement the same "cache only top importScript() calls"

[14:43:40.0000] <wanderview>
we're going to do that

[14:43:50.0000] <slightlyoff>
rad!

[14:44:00.0000] <slightlyoff>
/me does happy compatibility dance

[14:44:17.0000] <wanderview>
yea, good to be compatible and I like knowing when we are done caching

[14:44:33.0000] <wanderview>
slightlyoff: so I guess formalize that behavior in the spec?

[14:44:40.0000] <slightlyoff>
yep!

[14:44:49.0000] <wanderview>
awesome, thanks!

[14:48:55.0000] <TabAtkins>
+1


2015-02-27
[20:17:57.0000] <tantek>
has anyone blogged about the latest longdesc fiasco, or is the "consensus" just to ignore it and move on?

[20:22:26.0000] <caitp->
consensus doesn't exist on the web

[20:22:28.0000] <caitp->
or anywhere else

[20:24:00.0000] <tantek>
caitp: any posts about it you know of? like pointing out all the crazy?

[20:24:52.0000] <caitp->
haven't seen any mention of it today

[21:24:43.0000] <roc>
?

[21:30:24.0000] <tantek>
hey roc

[22:44:40.0000] <tantek>
caitp: I posted https://twitter.com/t/status/571184745008095233

[22:58:54.0000] <annevk_>
I wonder whether it's time that CSSOM starts properly defining the side effects of accessing clientHeight et al: https://bugzilla.mozilla.org/show_bug.cgi?id=1135960

[00:20:58.0000] <annevk>
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2LXKVWYkOus this is so great

[00:21:49.0000] <jochen__>
\o/

[00:23:10.0000] <annevk>
before you get too excited, overall peers at Mozilla didn't seem super compelled when I proposed something similar a while back

[00:23:17.0000] <annevk>
but hopefully eventually

[00:33:20.0000] <jochen__>
yeah, I guess we'll have to look at it on a case by case basis

[00:33:47.0000] <jochen__>
e.g. for geolocation, numbers on HTTP are surprisingly low, and the numbers of granted geolocation are even lower

[00:33:56.0000] <jochen__>
so it might not be a big deal for users anyway

[00:34:14.0000] <jochen__>
i'm kinda sad that there's still the argument that experimentation on http should work

[00:34:22.0000] <jochen__>
web developers should experiment on https

[00:37:54.0000] <annevk>
Yeah, with GitHub and localhost exception I don't really think that's an argument

[00:38:40.0000] <annevk>
I think for Web Crypto the argument has been that it can be polyfilled and that therefore there's no additional functionality, but that discounts that Web Crypto cannot be safe without TLS...

[00:39:21.0000] <annevk>
For geolocation and WebRTC it's been a combination of "too late now" and some more spurious arguments

[00:39:56.0000] <jochen__>
well

[00:40:00.0000] <jochen__>
numbers say it's not too late

[00:40:01.0000] <annevk>
Some of the others I had not considered though Joel's rationale makes sense

[00:40:11.0000] <annevk>
jochen__: that's certainly encouraging

[00:43:09.0000] <annevk>
jochen__: WebRTC WG was quite hostile to the idea, but forcing their hand works for me

[00:43:12.0000] <annevk>
jochen__: see e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=26937#c3

[00:44:22.0000] <annevk>
Anyway, looking forward to updates :-)

[00:45:09.0000] <jochen__>
yeah

[00:45:17.0000] <jochen__>
currently, we're in the process of collecting usage numbers

[00:45:28.0000] <jochen__>
and based on these, we'll propose concrete steps to move forward on a per feature basis

[01:08:20.0000] <JakeA>
wanderview: yeah, I like the simplicity of that model. It means you can't use a sharedworker offline from a SW unless a document initiates it. Buuuuuuuut I don't think that's a problem

[01:31:44.0000] <zcorpan>
good news everyone, http://www.w3.org/TR/2015/REC-html-longdesc-20150226/

[01:34:06.0000] <Ms2ger>
You're late :)

[01:48:20.0000] <zcorpan>
  if (i.longdesc)

[02:03:07.0000] <Ms2ger>
Why not have .longdesc and .longDesc both?

[02:06:29.0000] <gsnedders>
Anyone got a link to the IR for advancement to PR?

[02:10:10.0000] <gsnedders>
/me wonders what implementations they used

[02:21:04.0000] <zcorpan>
Ms2ger: thank you! i've never tried 99% before, will report back whether i like it :-)

[02:28:21.0000] <jgraham>
"Just a spoon full of cocoa poweder helps…" actually I don't know why you would want a spoon full of cocoa powder. Except for baking, I suppose.

[02:29:53.0000] <gsnedders>
jgraham: because everything should be chocolatey. EVERYTHING.

[02:34:10.0000] <zcorpan>
i usually put a teaspoon of cocoa powder in my protein shake

[02:40:40.0000] <Ms2ger>
zcorpan, I thought you'd like to try it :)

[02:42:08.0000] <MikeSmith>
fyi for people who love uri schemes https://mailarchive.ietf.org/arch/msg/ietf-announce/VGP7bgN8BN1kv2TDdE5d7-3w2Ug

[02:42:32.0000] <MikeSmith>
BCP request fo 'Guidelines and Registration Procedures for URI Schemes'

[02:44:00.0000] <MikeSmith>
> The file can be obtained via [URL that isn't a hyperlink because IETF's online-mail-archive software doesn't even turn URLs in messages into hyperlinks...]

[02:44:42.0000] <MikeSmith>
http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04

[02:45:36.0000] <MikeSmith>
the registration procedures are at http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04#section-7

[02:49:52.0000] <MikeSmith>
anyway, here's an idea for a better procedure: move all the registries into github repos and you just submit a PR for any new uri-scheme or media-type or whatever registrations

[02:51:25.0000] <MikeSmith>
that way the registries are all under publicly accessible version control, so you can see the history, etc., and changes are tied to referencable issues/PRs, etc

[02:51:46.0000] <Ms2ger>
Hehehehehe

[04:38:57.0000] <MikeSmith>
hsivonen: given the Codehaus news and the fact Jetty moved to Eclipse some time ago but the current validator dependency is still an outdated version that's only available from Codehaus, seems like it's probably time to update the dependency to a new version of JettyーI guess the latest version

[04:47:00.0000] <GPHemsley>
https://bugzilla.mozilla.org/show_bug.cgi?id=1060767

[04:49:26.0000] <GPHemsley>
https://bugzilla.mozilla.org/show_bug.cgi?id=1133409

[07:28:01.0000] <beverloo>
annevk, which version of anolis do you use?

[07:28:12.0000] <annevk>
beverloo: I'm not sure

[07:28:16.0000] <beverloo>
when I run it on the notifications spec I get a ton of changes in Overview.html unassociated with my changes

[07:28:52.0000] <Ms2ger>
Port to bikeshed first? :)

[07:28:57.0000] <annevk>
beverloo: I might have updated Anolis meanwhile and not regenerated that specification...

[07:31:17.0000] <beverloo>
I like the irony in the bikeshed project's name

[07:31:33.0000] <beverloo>
the notifications spec isn't too big, I'm happy to volunteer to do the conversion if that's desired?

[07:31:42.0000] <annevk>
beverloo: so... only comment I have on that PR is that I avoid newlines within <span> and such so I can more easily search and replace

[07:32:02.0000] <annevk>
beverloo: yeah that would be welcome

[07:32:46.0000] <Ms2ger>
It'll be a good day when I can finally retire anolis

[07:33:06.0000] <hsivonen>
MikeSmith: I've missed the codehaus news, but updating to latest makes sense

[07:36:18.0000] <beverloo>
annevk, ok, I'll change that. do you want me to include a regenerated overview.html?

[07:36:33.0000] <annevk>
beverloo: yeah I think that's fine

[07:36:39.0000] <beverloo>
annevk, I hereby sign up then. I'll regret this, won't I? :)

[07:36:51.0000] <annevk>
beverloo: dunno, we'll find out :-)

[07:47:11.0000] <beverloo>
annevk, amended

[07:47:37.0000] <annevk>
JakeA: so the alternative for use*URL is to just require a redirect, or would that be too cumbersome on authors?

[07:57:49.0000] <annevk>
beverloo: seems you forgot to add your name

[07:59:00.0000] <annevk>
Hmm it does seems like my copy of Anolis sorts attributes differently

[07:59:21.0000] <annevk>
Maybe I'll wait for the bikeshed conversion then to add that name

[07:59:37.0000] <beverloo>
sure

[07:59:51.0000] <annevk>
Well, I guess it doesn't matter, Overview.src.html can be used for sane diffs

[08:00:07.0000] <MikeSmith>
hsivonen: ok, will update

[08:00:20.0000] <beverloo>
annevk, I pulled anolis from ms2ger's hg repo just now

[08:00:32.0000] <beverloo>
1.3pre

[08:02:57.0000] <annevk>
1.2pre :-)

[08:31:44.0000] <wanderview>
annevk++

[08:31:55.0000] <wanderview>
for switzerland :-)

[08:31:59.0000] <annevk>
hehe

[08:38:12.0000] <wanderview>
JakeA: do you know what blink does when an https response is stored in the Cache?  does it save certificate and trust info as well?

[08:38:26.0000] <wanderview>
as far as I can tell, that type of information is not represented in the fetch Response object

[11:24:15.0000] <TabAtkins>
beverloo: Or I can help with the conversion; converting Anolis specs to Bikeshed well is a little tricky.


2015-02-28
[19:04:29.0000] <MikeSmith>
the HTML parsing algorithm never requires a UA to do charset conversion, right?

[19:05:27.0000] <MikeSmith>
and the spec otherwise has no requirements for UA to do any charset conversion?

[19:14:44.0000] <MikeSmith>
hmm "Convert the name and value strings to their byte representation in ISO-8859-1"

[01:08:34.0000] <JakeA>
https://twitter.com/JustRogDigiTec/status/571531063987601408?s=09

[01:08:42.0000] <JakeA>
This is truth

[01:09:59.0000] <JakeA>
A getRangesForText/getRangeForText method would be pretty useful. Doing it manually is not straight forward.

[01:24:02.0000] <annevk>
JakeA: file a bug?

[01:24:19.0000] <annevk>
JakeA: do please do explain usage scenarios and such